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APPLICATION  OF  COMBAT  PLANNING  TECHNOLOGY 
TO  RPV  COMMAND  AND  CONTROL 

ABSTRACT 


The  material  presented  herein  contains  the  Final  Report  for  a  study  of  the 
requirements  to  command  and  control  RPV  missions.  Factors  considered 
include  the  RPV  System  Concepts  as  they  have  evolved  over  the  past  several 
years,  technology  factors  as  they  impact  system  capability  and  system  costs, 
and  the  employment  concepts  which  encompass  the  use  of  RPV  Weapon  Sys¬ 
tems  in  both  a  mixed  force  and  a  pure  RPV  deployment. 

The  study  was  planned  as  a  confined  effort.  It  was  not  the  intent  to  analyze 
in  depth  all  factors  impacting  RPV  Command  and  Control,  but  rather  to 
assimilate  the  conclusions  of  the  many  studies  of  RPV  systems  that  have 
been  conducted,  and  to  integrate  these  results  with  Litton’ s  analysis  of 
Air  Force  mission  planning,  monitoring,  and  control,  and  thus;  to  derive  a 
viable  concept  for  an  RPV  Command  and  Control  system. 

This  report  addresses  the  requirements  for  planning  RPV  missions  and  for 
controlling  and  monitoring  the  missions  so  the  planned  mission  objectives 
will  be  realized.  Functional  requirements  have  been  identified  as  physical 
control  and  force  control.  Physical  control  is  defined  as  that  control  intro¬ 
duced  into  the  RPV  vehicle  system  that  causes  the  vehicle  to  fly  a  preplanned 
flight  profile  and  to  realize  a  preplanned  schedule.  It  is  comparable  to  that 
control  exercised  by  the  pilot  in  a  manned  aircraft  system.  Force  control  is 
defined  as  encompassing  all  functions  required  to  assign  resources  to  a  mis¬ 
sion  and  to  plan  the  mission  profile  and  schedule  so  the  mission  objective  is 
achieved.  This  planning  encompasses  requirements  to  coordinate  missions 
in  time  and  space,  to  plan  supporting  (communications  relay)  operations,  and 
to  plan  for  various  contingencies.  Included  in  the  force  control  function  is 
the  replanning  required  to  adjust  operations  in  response  to  unforeseen 
events  or  to  changed  environmental  factors  (i.  e.  ,  intelligence,  weather, 
requirements). 

Analysis  of  these  basic  functions  reveal  two  primary  interfaces  that  signifi¬ 
cantly  impact  the  control  functions.  One  is  the  physical  control/ RPV  vehicle 
interface.  The  other  primary  interface  is  that  between  the  planning  function 
and  the  physical  control  function.  Each  of  these  interfaces  dictate  system 
requirements  unique  to  unmanned  airborne  vehicles. 

An  assumption  which  is  especially  significant  in  the  selection  of  requirements 
for  command  and  control  of  RPVs  is  that  the  system  shall  provide  the  capa¬ 
bility  for  a  single  controller  to  control  multiple  RPVs.  The  only  exception 
is  that  over-the-target  control  of  each  strike  mission  requires  full  time  opera¬ 
tor  attention  for  a  short  period.  To  provide  this  capability,  analysis  indicated 
that: 


•  There  must  be  an  automatic  flight  control  system  (AFSC)  in  the 
RPV. 


ill 


•  For  RPV  control,  continuous  communications  with  the  RPV  under 
control  is  not  required  except  in  the  over -the -tar get  phase  and 
for  bomb  damage  assessment. 

•  Over -the -target  control  of  strike  missions  and  BDA  require  two 
way,  broadband  communications  on  demand. 

The  command  and  control  procedures  and  the  associated  data  processing  and 
display  requirements  discussed  in  this  report  were  developed  in  consonance 
with  these  assumptions  and  constraints. 

The  conclusion  of  the  analysis  of  the  requirements  is  that  the  system  providing 
RPV  command  and  control  elements  may  be  airborne  or  ground-based,  The 
command  and  control  elements  consist  of  a  DCF  multiple  RPV  control  that  can 
be  augmented  by  adding  modules  as  the  number  of  simultaneous  missions 
increase.  These  basic  elements  include; 

(1)  The  Multiple  RPV  Mission  Control  Element  which  provides 
capability  to  launch  an  RPV,  fly  the  RPV  on  a  preplanned 
flight  profile,  and  recover  the  vehicle. 

(2)  The  Weapon  Delivery  Control  Element  for  strike  missions 
which  provides  the  capability  to  receive,  process,  and 
display  in  real  time  the  video  imagery  obtained  from  the 
BO  sensors  on  board  the  strike  RPV. 

The  RPV  Mission  Planning  and  Force  Control  Element 
which  provides  the  system  with  capability  to  plan  a 
mission,  to  monitor  the  execution  of  missions,  and  to 
replan  and  adjust  operations  as  required. 

The  RPV  Force  Planning  and  Monitoring  Element  for  the  mixed  force  of  RPV 
and  manned  aircraft  is  the  485L  T ACC  which  is  considered  to  be  external  to 
the  RPV  command  and  control  system.  The  report  provides  data  processing, 
communications,  and  operator  consoles  and  display  requirements  for  each 
system  element. 
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SECTION  1 
STUDY  OBJECTIVES 


1 . 1  INTRODUCTION 

The  information  in  this  report  presents  the  findings  of  a  four  man-month  effort 
on  Remotely  Piloted  Vehicles  (RPV)  Command  and  Control  requirements.  The 
study  was  conducted  as  an  add-on  to  Litton' s  existing,  "Mission  Planner  Pro¬ 
gram"  (USAF  Contract  No.  F30602-71 -C-001 5).  It  was  postulated  that  the  Com¬ 
mand  and  Control  functions  for  manned  aircraft  in  tactical  situations  as  devel¬ 
oped  in  the  Mission  Planner  Program  were,  in  many  cases,  directly  relevant  to 
RPV,  The  purpose  of  this  study  was  to  validate  and  define  the  extent  of  com¬ 
monality  between  the  command,  control,  and  communications  functions  identi¬ 
fied  in  the  Mission  Planner  Program  and  those  required  for  RPV  utilization. 

1.2  STUDY  BASIS 

The  Advanced  Development  Mission  Planner  System  (ADMPS)  is  presently 
being  conducted  as  a  part  of  the  ground  data  processing  element  (691F)  of  the 
Advanced  Development  691  "Force  Protection  Program".  The  ADMPS  is 
sponsored  by  USAF  Rome  Air  Development  Center,  but  because  it  places 
emphasis  in  Force  management  and  vehicle  utilization  planning,  the 
present  RPV  addendum  is  being  monitored  by  USAF  Electronic  Systems 
Division  of  Air  Force  Systems  Command,  The  ADMPS  is  being  designed 
to  provide  automated  support  for  the  detailed  planning  {and/or  simulation) 
of  tactical  air  missions  using  manned  aircraft.  A  cursory  examination 
reveals  that  the  ADMPS  functions  are  equally  applicable  to  unmanned  as 
well  as  manned  vehicles. 

Although  the  ADMPS  itself  is  not  complete,  an  intermediate  milestone  of  that 
development  required  a  demonstration  of  concept  feasibility.  For  this  demon¬ 
stration  a  set  of  software  programs  which  implemented  the  total  spectrum  of 
planning  functions  to  support  strike  and  ECM  mission  planning  ware  generated. 
This  implementation,  successfully  demonstrated  in  December  of  1971,  is 
called  the  Mission  Planner  Breadboard  System  (MPBS).  MPBS  operates  on 
commercial  equipment  and  has  been  demonstrated  to  interested  audiences 
from  its  inception  to  the  present  time  at  Eglin  Air  Force  Base  and  at  Litton' s 
Canoga  Park  Facility.  It  was  the  demonstration  of  this  breadboard  that  lead 
to  the  present  study,  The  functions  and  operation  of  the  breadboard  are 
detailed  in  Section  4  of  this  report,  along  with  the  description  of  the  RPV 
demonstration  and  an  analysis  of  how  MPBS  might  be  modified  for 
RPV  purposes. 

1.3  STUDY  TASKS 

Task  X.  RPV  Mission  Planring:  Determine  the  applicability  and 
demonstrate  the  utm  of  current  Mission  Planning  programs  to  RPV 
mission  planning  requirements. 
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Task  II.  Real  Time  Command  apd  Control  Requirements:  Identify 
and  describe  those  functions  which  shou’d  be  implemented  to  satisfy 
the  RPV  requirements  for  '♦eal  time  Co.nmrnd  and  Control  and  their 
hardware  and  software  impact. 

1.4  SCOPE 

The  effort  expended  on  this  study  was  limited  by  funding  to  approximately 
four  man-months  of  effort  plus  the  computer  time  required  for  demonstrating 
the  present  applicability  of  the  MPBS  to  RPV.  To  determine  how  applicable 
the  MPBS  functions  might  be  to  RPV  command  and  control,  however,  (and  to 
plan  the  demonstration),  analysis  of  the  Command  and  Control  requirements 
imposed  by  the  nature  of  the  RPV  itself  was  necessary.  To  perform  such 
analysis  within  the  prescribed  limits,  results  had  to  be  based  on  the  data  of 
existing  studies  and  analyses  rather  than  upon  a  totally  new  analysis.  In 
some  areas,  such  as  assumptions  concerning  the  avionics  and  performance 
capabilities  of  the  P.PV,  it  was  necessary  to  use  existing  data  as  a  "given." 
Similarity,  development  of  the  data  processing  estimates  are  primarily 
based  upon  Litton1  s  substantial  experience  in  the  development  of  tactical 
Command  and  Control  Systems.  The  particular  studies  and  analyses  used, 
together  with  a  specific  analysis  of  the  RPV  communication  problem,  are 
presented  in  Section  Z, 

The  major  portion  of  the  study  is  contained  in  Section  3.  This,  section  pre¬ 
sents  the  results  of  the  functional  analysis  and  describes,  where  appropriate, 
how  Mission  Planner  function?  fit,  or  could  be  modified  for  RPV,  The  defi¬ 
nition  of  functional  requirements  has  been  taken  to  a  level  of  indenture  suffi¬ 
cient  to  provide  functional  allocation  to  data  processing,  display,  communica¬ 
tions,  or  operator  subsystems.  Once  the  functions*  analyses  are  made  it  is 
possible  to  evaluate  the  data  base  and  processing  requirements.  These 
requirements  are  presented  in  Section  5, 

Section  6  of  this  report  presents  the  System  Concepts  for  Command  and  Con¬ 
trol  of  RPVs,  Including  conceptual  system  design.  Section  7  identifies  areas 
for  additional  study, 

1.  5  RPV  FORCE  DEPLOYMENT  FACTORS 

The  force  deployment  assumptions  are  based  upon  guidance  provided  for  this 
study  and,  as  they  relate  to  RPV  strike  units,  on  guidance  provided  for  the 
man-machine  interface  studies.  The.  factors  which  are  documented  in  this 
section  are  applied  in  Section  3,  RPV  Command  and  Control,  and  Section  4, 
Mission  Planning  Systems  Applications  to  RPV  Command  and  Control,  to 
establish  quantitative  factors  for  operator  requirements  and  data  processing 
and  display.  In  many  areas,  these  factors  are  relatively  independent  of 
mission  type.  Consequently,  the  results  are  relatively  independent  of  the 
mission  mix.  The  factors  that  most  significantly  affect  system  capacity  are; 

a.  Total  number  of  mission's  per  day  and  planning  response  times 
required 

b.  Total  number  of  missions  simultaneously  airborne 
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c.  Total  number  of  strike  missions  simultaneously  in  the  weapon 
delivery  phase. 

The  standard  RPV  force  assumed  is  an  RPV  Composite  Group  with  three 
units;  a  Strike  unit,  and  EW  unit,  and  a  Reconnaissance  unit.  Each  unit  is 
capable  of  launching  80  sorties  par  day.  There  will  be  up  to  20  missions 
simultaneous  airborne.  Four  strike  missions  may  be  in  the  terminal  phase 
simultaneously.  Table  I.  5-1  RPV  Force  Factors,  tabulates  all  factors 
assumed. 


Tabic  1.5-1  RPV  Force  Factors 

No.  Units  3 

Sorties  per  Unit/ Day  80 

Sorties  per  Mission  i 

Total  Missions/Day  240 

Targets /Mission,  Strike  3 

Targets/Recce  Mission  3 

Mission  Objectives  per  EW  Mission  .  2 

Total  Simultaneous  Mis  a  ions /Unit  20 

Total  Simultaneous  Missions/RPV  Force  60 

Total  Simultaneous  Strike  Missions 

Cvor-the- Target  4 

Launch  Sites  per  Unit  2 

Total  Launch  Sites  6 

Recovery  Sites  per  Unit  1 

No.  Emergency  Recovery  Sites  1 

Total  Recovery  Sites /Force  4 

i . . . . . .  .  . 

1.6  SUMMARY  AND  CONCLUSIONS 


The  material  presented  in  this  report  is  based  upon  a  study  of  the  require¬ 
ments  to  command  and  control  RPV  missions.  Factors  considered  have 
included  the  RPV  System  Concepts  as  they  have  evolved  over  the  past  seteral 
years,  technology  factors  as  they  impact  system  capability  and  system  costs, 
and  the  employment  concepts  which  encompass  the  use  of  RPV  Weapon  Systems 
in  a  mixed  force  as  well  as  in  a  pur*  RPV  deployment. 

The  study  was  planned  as  a  confined  effort.  It  was  not  the  intent  to  analyze 
in  depth  all  factors  impacting  RPV  Command  and  Control,  but  rather  assimi¬ 
late  the  conclusions  of  the  many  studies  of  RPV  systems  that  have  been  con¬ 
ducted,  to  integrate  these  results  with  Litton’ s  analysis  of  Air  Force  mission 
planning,  monitoring,  and  control  and  to  derive  a  viable  concept  for  an 
UPV  Command  and  Control  system. 
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In  consonance  with  this  study  plan  the  report  summarizes  briefly: 

•  Operational  concepts  for  the  employment  of  RPVs. 

•  Air  Force  funded  studies  that  have  been  used  as  a  basis  for  the 
RPV  system  performance  capabilities. 

•  Litton's  studies  of  mission  planning  and  control  systems 
applicable  to  RPV  Command  and  Control. 

Because  communications  for  enroute  and  over-the -target  control  introduces 
significant  technological  problems,  a  detailed  discussion  of  communications 
technology  as  it  applies  to  RPV  control  is  included. 

The  report  addresses  the  requirements  for  planning  RPV  missions  and  for 
controlling  and  monitoring  the  missions  so  the  planned  mission  objectives  will 
be  realized.  Functional  requirements  have  been  identified  as  physical  control 
and  force  control. 

Physical  control  is  defined  as  that  control  introduced  into  the  RPV  vehicle 
system  that  causes  the  vehicle  to  fly  a  preplanned  flight  profile  and  to  realize 
a  preplanned  schedule.  Over-the -target  control  for  weapon  delivery,  on- 
station  control  (or  EW  and  reconnaissance  missions,  and  control  required  to 
respond  '  3  system  failures  are  subsumed.  It  is  comparable  to  that  control 
exercised  by  the  pilot  in  a  manned  aircraft  system. 

Force  control  Is  defined  as  encompassing  all  functions  required  to  assign 
resonrcue  to  a  mission  and  to  plan  the  mission  profile  and  schedule  so  the 
mission  objective  i'  achieved. 

This  planning  encompasses  requirements  to  coordinate  missions  in  time  and 
space,  to  plan  suppor  ting  (communications  relay)  operations,  and  to  plan  for 
various  contingencies.  Subsumed  in  the  Force  control  function  is  the  replan¬ 
ning  roquired  to  adjust  operations  in  response  to  unforeseen  events  or  to 
changed  environmental  factors  (i.  e. ,  intelligence,  weather,  requirements). 

There  are  two  orlmary  interfaces  that  significantly  impact  the  control  func¬ 
tions.  One  is  the  physical  cont*  >l/RPV  vehicle  interface.  Principal  assump¬ 
tions  used  in  this  study  on  the  RPV  system  are  derived  from  the  £iv  Force 
Multi-Mission  Studies.  Physical  control  requirements  are  developed  by  mis¬ 
sion  phase:  i.a. ,  launch,  enreute,  over -the -target  strike  or  on-station  EW 
and  Recce,  return  to  base,  and  recovery.  Other  assumptions  on  the  RPV 
vehicle /physical  control  interface  are  documented  throughout  the  section  in 
the  particular  mission  phase  vero  they  app’y. 

The  other  primary  interface  i<*  that  between  the  planning  function  and  the 
physical  control  function.  In  considering  this  interface,  it  wan  concluded 
that  the  RPV  mission  is  re'atively  unique  since  there  is  little  opportunity  to 
obtain  knowledge  of  the  flight  environment  in  the  execution  phase  that  was  not 
available  before  launch.  Specifically,  visual  reference  to  mu  environment 


is  very  limited  vis-a-vis  that  possible  in  a  manned  system.  Consequently, 
the  conclusion  was  that  planning  could  and  should  be  very  detailed  and  com¬ 
prehensive.  The  principal  requirement  for  physical  control  is  to  insure  mis¬ 
sions  are  executed  as  planned.  The  procedures  for  physical  control  are  based 
on  this  premise.  Force  Control  Functions  show  how  such  detailed  plans  are 
generated. 

The  assumption  which  is  especially  significant  in  the  selection  of  requirements 
for  command  and  control  of  RPVs  is  that  the  system  shall  provide  the  capabil¬ 
ity  for  a  single  controller  to  control  multiple  RPVs.  The  only  exception  is 
that  over-the-target  control  of  each  strike  mission  requires  full  time  opera¬ 
tor  attention  for  a  short  period.  To  provide  this  capability,  analysis  indicated 
that: 


a.  There  must  be  an  automatic  flight  control  system  (AFCS)  in  the 
RPV.  The  AFCS  will,  at  a  minimum,  provide  the  capability  to 
maintain  (hold)  attitude  and  heading.  Additionally,  it  was  con¬ 
cluded  that  the  requirement  to  provide  control  of  multiple  RPVs 
in  a  hostile  environment  dictated  that  the  AFCS  also  have  the 
cap  bility  to  initiate  and  execute  maneuvers  such  as  turn,  climb, 
and  descend. 

b.  For  RPV  control,  continuous  communications  with  the  RPV  under 
control  is  not  required  except  in  the  over-the-target  phase  and  for 
bomb  damage  assessment.  Contact  intervals  in  the  order  of 

10  seconds  are  judged  to  be  acceptable;  longer  periods  between 
contacts  are,  however,  tolerable  under  certain  conditions.  In 
addition,  the  physical  control  procedures  developed  do  not  require 
communications  to  execute  a  preplanned  RPV  maneuver  at  an 
exact  time.  The  consequence  of  these  conclusions  is  that  require¬ 
ments  for  the  communications  relay  subsystem  are  considerably 
reduced  with  resper  to  physical  control.  Thus,  lower  cost  imple¬ 
mentation  of  the  command/ response  links  are  available  as  viable 
options.  The  communications  factors  documented  in  Subsec¬ 
tion  2.4  derive  from  these  premises. 

c.  Over -the -target  control  of  strike  missions  and  BDA  require  two 
way  communication  on  demand,  A  broad  band  data  link  to  trans¬ 
mit  imagery  from  the  RPV  to  the  Drone  Control  Facility  (DCF) 
Controller  (ground-based  or  airborne)  is  required.  The  com¬ 
mand  link,  Controller  to  RPV,  must  also  be  available  on  demand, 

The  command  and  control  procedures  and  the  associated  data  processing  and 
display  requirements  were  developed  in  consonance  with  these  assumptions 
and  constraints.  Additionally,  the  desirability  of  minimising  on-board  proc¬ 
essing  in  the  RPV  and  minimizing  communications  requirements  was  sub¬ 
sumed.  The  conclusion  of  the  analysis  of  the  requirements  for  command  and 
control  is  that  the  system  providing  RPV  command  and  control  elements 
may  be  airborne  or  ground-based.  The  command  and  control  elements,  in 
turn,  consist  of  a  DCF  multiple  RPV  control  element  that  can  be  augmented 
by  adding  modules  as  the  number  of  simultaneous  missions  increase.  Figure 
1.6-1  shows  in  specification  tree  format  the  mission  essential  elements  of 
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Figure  1.6-1.  RPV  System  Specification  Tree 


the  RPV  system.  Those  elements  which  are  either  a  part  of,  or  are  principal 
interfaces,  with  the  RPV  control  system  are  shown  in  bold  outline.  The  sig¬ 
nificant  conclusions  of  this  study  relate  to  the  features  of  the  RPV  command 
and  control  element  modules. 

The  Multiple  RPV  Mission  Control  Element  provides  the  capability  to  launch 
an  RPV,  fly  the  RPV  on  a  preplanned  flight  profile,  and  recover  the  vehicle. 
The  capability  to  provide  inflight  control  and  to  react  to  exceptions  reported 
is  included.  This  element  consists  of  personnel,  data  processing  and  opera¬ 
tor  consoles  and  is  common  to  ail  RPV  units;  Strike,  EW,  and  Reconnais¬ 
sance.  It  is  the  essential  element  required  in  every  deployment  situation. 

The  Weapon  Delivery  Control  Element  for  strike  missions  provides  the  capa¬ 
bility  to  receive,  process,  and  display  in  real  time  the  video  imagery  obtained 
from  the  EO  sensors  on  board  the  strike  RPV.  The  element  also  provides  the 
capability  to  position  the  strike  RPV  exactly  on  a  delivery  trajectory  and  to 
control  weapon  release  and  bomb  damage  assessment.  This  element  aug¬ 
ments  the  basic  element.  Consequently,  die  DCF  for  an  RPV  strike  unit  con¬ 
sists  of  the  basic  element  plus  the  Weapons  Delivery  Control  Element.  The 
element  contains  operator  personnel,  strike  control  consoles,  and  additional 
data  processing  capability. 

The  RPV  Mission  Planning  and  Force  Control  Element  J3  the  system  element 
that  provides  the  capability  to  plan  a  mission,  to  monitor  che  execution  of 
missions,  and  to  replan  and  adjust  operations  as  required.  It  also  establishes 
requirements  for  mission  support,  e.g,,  EW  support  to  a  strike  or  recon¬ 
naissance  mission.  It  automatically  generates  a  code  as  a  part  of  the  plan 
which  can  be  inserted  into  the  RPV  prior  to  launch,  or  transmitted  to  the 
RPV  inflight.  The  coding  is  such  that  the  RPV  wJJl  i  louver  according  to 
the  preplanned  flight  profile  within  dead  reckoning  accu.icy  Limits.  (It  is 
operationally  desirable  that  this  capability  also  be  available  in  the  Multiple 
RPV  Mission  Control  Element  for  cases  when  the  two  modules  are  not  colo¬ 
cated.  The  element  consists  of  operator  personnel,  data  processing,  and 
operator  consoles.  Since  this  element  requires  relatively  complete  data  on 
the  enemy  order  of  battle,  (especially  targets  and  enemy  defense  capability) 
and  other  data  applicable  to  all  RPV  units,  it  it  sized  to  plan  and  monitor  the 
operations  of  the  total  RPV  force.  The  level  of  capability  provided  is  essen¬ 
tial  to  an  effective  and  rapid  response  planning  capability  and  is  typically 
required  in  all  deployments.  However,  if  mission  requirements  are  simple 
and  the  RPV  force  is  small,  the  option  of  manual  planning  does  exist.  RPV 
flight  profiles  can  be  manually  generated.  Conversion  to  code  can  be  accom¬ 
plished  by  the  Multiple  RPV  Control  Element,  For  a  pure  RPV  force,  the 
planning  element  supports  the  force  planning  function. 

The  RPV  Force  Planning  and  Monitoring  Element,  for  the  mixed  force  of 
RPV  and  manned  aircraft,  is  the  485L  TACC.  This  element  is  considered  to 
be  external  to  the  RPV  system.  The  additional  capability  desirable  or  re¬ 
quired  within  the  TACC  to  effectively  plan  a  mixed  force  operation  is  ad¬ 
dressed  in  Subsection  3.3,  Force  Planning  Function.  This  is  reflected  as 
a  dotted  line  box  in  Figure  1,6-1. 


Tli*  Real  Tima  Reconnaie* anc  e  Data  Processing  Element  provides  the 
capability  to  receive  and  process  in  near  real  time  reconnaissance  imagery 
data  and  other  reconnaissance  information.  It  augments  the  basic  module 
for  reconnaissance  RPV  units  if  this  capability  is  required.  Since  the  capa¬ 
bility  to  process  reconnaissance  data  in  near  real  time  is  common  to  manned 
aircraft  and  RPV*  alike,  the  element  may  be  an  element  of  the  intelligence 
processing  system,  not  the  RPV  system.  Thus  it  is  shown  as  a  broken  line 
box  and  is  not  addressed  in  this  study.  There  is,  however,  a  significant 
interface  that  will  affect  the  Recce  RPV. 

Figure  1.  6-2  depict*  the  RPV  command  and  control  system  in  a  typical 
deployment  situation  with  three  RPV  units.  Interfaces  between  each  RPV 
unit  and  the  planning  element  is  depicted.  A  digital  data  link  interface  ie 
assumed.  Each  unit  interfaces  directly  with  launch  and  recovery  sites;  again 
digital  data  link  is  assumed.  Interface  with  the  TACS  system,  the  TACC, 
CRC,  and  manned  aircraft  unit  TUOCs  is  through  the  RPV  composite  group 
planning  and  Monitoring  modular  element.  Not  shown  on  the  figure  is  the 
interface  with  the  airborne  RPVs  which  is  from  the  unit  control  module  to 
the  RPV,  either  direct  or  through  the  relay  aircraft. 


Figure  1.6*2,  RPV  C81C  System  Typical  Configuration 


SECTION  2 


RELATED  STUDIES  AND  TOPICS 


2.  1  INTRODUCTION 

A  principal  source  of  information  was  the  set  of  reports  derived  from 
various  Air  Force  studies  including  the  Multimission  Remotely  Piloted 
Vehicle  Systems  (Contract  Nos.  F33615-72-C- 1260  and  F33615-72-C- 1210), 
Man  Machine  Interface  (Contract  No.  F33615-72-C-  1848),  Command  and 
Control  Information  Processing  (CCIP-85  AF  Contract  No.  470I-71-C-0366), 
and  SEEK  FLEX  Preliminary  Design  (USAF  Contract  No.  F19628-7  1 -C-0016) 
studies.  Additional  data  were  derived  from  other  sources  including  a  docu¬ 
ment  entitled  "Navigation  and  Guidance  for  Remotely  Piloted  Vehicles, " 
which  was  presented  by  Litton  Guidance  and  Control  Systems  Division 
personnel  at  the  RPV  Symposium  (June  1972).  Other  documentation  includes 
the  TACOP  Final  Report  -  CORONET  ORGAN  V,  dated  1-11  November  1971; 
"An  Analysis  of  Remotely  Manned  Systems  for  Attacking  SAM  Sites,  "  USAF 
Rand  Project  Report  R-710-PR;  plus  numerous  articles  concerned  with 
drone/RPV  technology  and  utilization.  Key  technology  areas  that  have  im¬ 
pact  o»t  the  command  and  control  system  requirements  are  the  vehicle 
navigation  technique  and  the  vehicle-ground  communication  link.  The  re¬ 
quirements  for  these  two  elements  are  discussed  in  Subsections  2.6  and 
2.7.  Additional  areas  of  special  impact  are  the  structure,  size,  and 
deployment  concepts  of  Tactical  Air  Forces.  Brief  discussions  of  these 
are  included  in  Subsection  1.  5  and  Section  5. 

2. 2  RPV  SYSTEM  DESIGN  STUDIES 

Litton  used  previously  conducted,  USAF  funded,  studies  for  information 
pertaining  to  certain  areas  of  this  study.  This  applicable  data  included 
the  areas  of;  vehicle  design,  operational  concepts,  Force  sizes,  communi¬ 
cations  requirements,  facilities  required  for  Drone  Control,  and  analyses 
of  man-machine  Interfaces.  These  studies  covered  a  wide  range  of  factors 
pertinent  to  the  development  of  this  system.  Therefore,  they  contributed 
directly  to  this  study  because  it  was  not  intended  to  further  define  any  of 
these  factors  but  rather  to  select  representative  factors  from  thorn  as  a 
baseline. 
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2.2. 1  RPV  Multi-Mission  Studies 


Two  studies  were  awarded,  one  to  Tele  dyne -Ryan  assisted  by  RCA,  and  the 
other  to  Northrup  assisted  by  TRW,  to  determine  the  system  design  require¬ 
ments  for  remotely  piloted  vehicles  as  a  tactical  weapons  system  for  multiple 
mission  application.  These  design  requirements  included  consideration  of: 


Airframe  Technology 
Propulsion  Systems 
Avionics  Systems 
Sensors 


ECM  Vulnerability 
Vehicle  Control 
Ground  Handling 
Logistics 


The  findings  of  these  studies  provided  the  basis  for  defining  vehicle  capability, 
application,  and  operational  concepts.  In  addition,  they  provided  a  source  of 
navigation  accuracies  versus  CEP  requirements  tor  various  missions /target 
types. 

As  these  studies  developed  their  baseline  system,  the  keynote  was  operational 
flexibility,  simplicity,  and  growth  capability  rather  than  a  single  sophisticated 
configuration 


2.2.2  RPV  Man-Machine  Interface  Studies 

Two  studies  were  conducted  for  the  Air  Force,  one  by  North  American 
Rockwell  and  the  other  by  Sperry,  which  investigated  the  man-machine  inter¬ 
face  requirements  for  employing  remotely  piloted  vehicles  as  a  tacticai  wea¬ 
pon#  system  for  multi-mission  application.  Six  tasks  were  addressed  in 
these  studies  and  included  the  following: 

•  Mission  Definition  Study 

•  Functional  Analysis 

•  Determination  of  Selection  Criteria 

•  Trade-off  and  Sensitivity  Analysis 

•  Remote  Control  Station  Design 

•  Program  Definition 

A  targe  portion  of  the  effort  was  directed  to  the  definition  of  an  RPV  opera¬ 
tional  unit  organization.  The  organization  proposed  was  a  self-sufficient  unit 
consisting  of  vehicles,  launch  and  recovery  facilities,  a  control  element,  and 
support  units. 

The  functional  analysis  was  keyed  to  eight  mission  phases  which  included  Sys¬ 
tem  Readiness,  Pre-Launch  Activities,  Launch,  Navigation,  Target  Acquisi¬ 
tion,  Attack,  Bomb  Damage  Assessment,  and  Recovery.  The  analysis 
resulted  in  a  determination  of  the  level  of  automation  (from  0  to  100  percent) 
for  all  functions  identified.  All  functions  were  listed  with  an  indication  of 
whether  the  function  was  manual,  semi-automatic,  or  automatic.  The  results 
indicate  that  44  percent  of  the  functions  are  manual,  2B  percent  semi¬ 
automatic,  and  18  percent  automatic* 
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Subsystem  design  parameters  were  defined  for  each  of  the  major  subsystem 
elements,  such  as  displays,  controls,  and  operator  interface  mechanisms. 
Values  for  these  parameters  were  determined  via  a  series  of  selection  trade¬ 
offs.  The  basis  of  the  trade-offs  were  a  set  of  selection  criteria  which 
included  performance,  compatibility,  flexibility,  and  cost* 

As  a  result  of  the  functional  analysis  and  trade-off  studies,  several  viable  Re¬ 
mote  Control  Station  designs  were  developed  for  both  near  term  and  prototype 
application.  The  designs  varied  in  level  of  sophistication  and  automation. 

The  recommended  designs  were  one-operator  on  one-RPV,  with  heavy  opera¬ 
tor  interaction  for  the  near  term  and  one  man  on  multiple  RP Vs  for  the  prototype . 

2.  3  CCIP  85  STUDY 

2.3.1  -  Future  Data  Processing  Requirements  of  Tactical  Air  Forces  in 
the  19§0i 

In  the  summer  of  1971,  Litton  conducted  a  three-month  study  to  identify  the 
automatic  data  processing  required  to  support  tactical  Command,  Control 
and  Communications  for  the  employment  of  tactical  Air  Forces  in  the  1985 
time  frame.  The  study  was  prepared  for  the  Development  Planning  Study 
Group  that  was  organized  to  examine  ail  facets  of  ADP  support  for  Command, 
Control,  and  Communications  in  the  1980  to  1990  time  frame. 

Under  the  study  conducted  by  Litton,  the  requirements  to  plan,  monitor,  and 
control  tactical  air  operations  were  analyzed.  Specifically  the  following  func¬ 
tional  areas  were  addressed. 

•  Tactical  Air  Control  Center  {TACC)  function. 

•  Airlift  Control  Center  (ALCC)  function. 

•  Tactical  Airborne  Element  (TARE)  Combat  and  Combat 
Support  functions. 

•  Airlift  Control  Element  (ALOE)  and  Airlift  TABE  function. 

•  Direct  Air  Support  Center  (DASC)  function. 

•  Control  and  Reporting  Center/ Control  and  Reporting  Post 
(CRC/CRP)  functions. 

•  Sensor  Reporting  Post  (SRP)  functions. 

Under  this  study,  new  system  capabilities  were  addressed.  One  of  the  new 
system  capabilities  analyzed  was  remotely  piloted  vehicles.  A  conclusion  of 
the  study  was  that,  “'the  introduction  of  remotely  piloted  vehicles  (RPVs)  into 
the  inventory  does  not  in  itself  introduce  new  command  and  control  functions. 
There  are,  however,  a  number  of  factors  that  dictate  requirements  for  more 
detailed  planning  within  the  TACC.  One  of  these  factors  is  the  introduction 
of  RPVs  into  the  inventory,  *’ 
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The  present  study  of  RPV  command  and  control  has  been  able  to  use  data  and 
experience  developed  under  the  study  conducted  in  1971.  The  present  study 
has  developed  the  requirement  to  plan,  monitor,  and  control  RPV  missions  at 
the  TACC  in  significantly  greater  detail  than  is  required  for  manned  aircraft. 
Further,  under  the  present  study,  the  requirements  analysis  was  extended  in¬ 
to  the  area  of  physical  control  of  the  airborne  RPV,  (the  control  exerciseo  by 
the  remoted  controller)  which  was  not  addressed  in  the  previous  study. 

2.4  SEEK  FLEX  STUDY  AND  INITIAL  TACC  AUTOMATION  PROPOSAL 

In  August  1970  Litton  DSD  was  awarded  a  study  contract  oriented  toward 
obtaining  the  preliminary  design  and  performance  requirements  for  the  Data 
processing  and  Display  subsystems  for  an  automated  post- 1975  Tactical  Air 
Control  Center  (TACC).  The  principal  objectives  of  the  study  were  to: 

a.  Define  the  functions  of  the  post- 1975  TACC/ALCC. 

b.  Define  the  data  processing  and  display  requirements  which 
derive  from  the  functional  and  operational  requirements  of 
the  TACC/ALCC. 

c.  Determine  the  optimum  technical  approach  for  the  Automated 
TACC/ALCC* 

d.  Describe  and  define  the  recommended  design  approach* 

e.  Develop  an  implementation  plan  for  the  development  of  such 
a  system. 

The  SEEK  FLEX  preliminary  design  study  was  accomplished  through  a  multi- 
tasked  study  effort  organized  around  the  principal  objectives  outlined  above. 
Coordination  and  guidance  during  the  study  were  provided  by  representatives 
of  the  Electronic  System*  Division,  the  Tactical  Air  Command  and  the  Mitre 
Corporation. 

The  study  approach  contained  two  significant  innovations.  The  first  and  most 
significant  was  the  extensive  use  of  computer  modeling  to  determine  both  sys¬ 
tem  requirements  and  system  performance.  The  second  relates  to  the  docu¬ 
mentation  used  in  the  derivation  of  the  data  processing  requirements  and  the 
computer  interface  with  the  computer  modeling  activities. 

This  study  was  submitted  to  the  Air  Force  in  the  early  summer  of  1971.  In 
February  1972,  the  Air  Force  issued  a  Request  for  Proposal  (RFP)  for  Initial 
TACC  Automation  as  defined  in  USAF  System  Specification  001485.  Litton 
DSD  responded  to  this  RFP  with  a  proposal  which  at  present  ia  in  the  source 
selection  phase  with  a  contract  award  expected  in  January  1973. 

During  the  Study  effort  and  the  response  to  the  RFP,  Litton  DSD  gained  a 
detailed  understanding  of  the  functions  of  the  Tactical  Air  Control  System 
along  with  its  capabilities  and  limitations.  Also  gained  was  a  keen  apprecia¬ 
tion  for  the  external  and  internal  interfaces  required  of  this  control  system, 
and  how  a  change  of  function  effects  these  interfaces.  This  experience  has 
been  applied  to  this  study. 
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MISSION  PLANNING  ADVANCED  DEVELOPMENT  SYSTEM 


As  a  part  of  the  USAF  691  Force  Protection  Program,  Litton  is  in  the  process 
of  developing  a  computer  based  system  for  planning  ECM  and  tactical  air  mis¬ 
sions.  This  Advanced  Development,  when  completed,  will  provide  automated 
support  to  the  planning  organization  for  the  total  spectrum  of  tactical  air  mis¬ 
sion  types  (e.g.,  interdiction,  reconnaissance,  Close  Air  Support,  Air 
Defense,  etc.)  which  occur  in  a  tactical  environment. 

For  each  mission  type  the  following  functions  will  be  performed  as  appropriate; 

•  Target  Selection  and  Review 

•  Ordnance  Selection 

•  Airbase  and  Call  Sign  Selection 

•  Route/Profile  Planning  {Semi-Automatic  and  Automatic) 

•  Fuel  Calculations  and  Tanker  Requirements 

•  Tactical  Air  Control  System  Requirements 

•  Standoff  ECM  Support 

•  Enroute  ECM  Support 

•  Total  Plan  Review 

Subsection  4.2  of  this  report  describes  the  Mission  Planner  Breadboard  in 
detail.  This  breadboard  was  developed  as  a  milestone  in  the  design  and  fabri¬ 
cation  of  the  Advanced  Development.  It  differs  from  the  Advanced  Develop¬ 
ment  in  the  following  ways; 

a.  The  breadboard  is  limited  to  the  interdiction  and  ECM 
mission  types. 

b.  The  breadboard  data  base  is  limited  in  size. 

c.  Some  of  the  implementation  approaches  to  functional  perform¬ 
ance  in  the  breadboard  will  be  changed  In  the  Advanced  Devel¬ 
opment  for  greater  sophistication  and  reduction  in  required 
data  base. 

d.  Functions  which  are  unique  to  a  new  mission  type,  or  are 
presently  not  included  in  the  breadboard  ECM,  will  be  included 
in  the  Advanced  Development. 

In  general,  however,  the  referenced  breadboard  description  will  provide  the 
reader  with  a  good  understanding  of  the  planned  functional  capabilities  of  the 
Mission  Planner  Advanced  Breadboard. 

2.6  RPV  NAVIGATION  SUBSYSTEM 

Control  and  Navigation  subsystems  are  key  elements  for  the  effective  employ¬ 
ment  of  remotely  piloted  vehicles.  They  are  closely  related  and  the  degree 
of  sophistication  of  one  impacts  the  other,  A  review  of  previously  conducted 
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studies  indicate  a  "sheppirtg  lL»t"  of  capabilities  available  in  these  areas.  All 
these  studies  indicate  that  these  capabilities  are  within  the  current  state-of- 
the-art,  and  have  potential  projected  reductions  in  cost. 

These  subsystems  may  vary  from  a  completely  self-contained  Navigation 
system,  which  requires  little  or  no  upd?.ting  f’~om  vhe  Drone  Control  Facility, 
to  one  which  requires  continuous  updating  from  the  Control  Facility.  This 
cursory  evaluation  of  the  desired  capabilities  falls  between  these  extremes. 
Based  on  previous  work  with  the  Tactical  Air  Command,  (the  assumed  user) 
the  dynamic  nature  of  tactical  air  warfare  demands  close  control  of  the  vehicle 
by  a  human  operator  to  enhance  the  effective  employment  of  the  system.  It 
appears  therefore,  that  the  minimum  navigation  capability  required  is  one  that 
provides  enroute  control  of  the  vehicle  during  ingress  and  egress  from  the 
target  area,  reports  vehicle  status,  and  accepts  corrections  during  flight. 

The  following  features  should  be  considered  in  determining  the  navigational 
capabilities  of  the  Remotely  Piloted  Vehicle; 

a.  Partially  self-contained  to  afford  recovery  if  communications 
are  interrupted. 

b.  Fully  secure  to  prevent  enemy. 

c.  World-wide  employment  capability. 

d.  Rer  '  rtable  status  such  as  position,  speed,  heading,  and 
altitude;  on  command. 

e.  No  altitude,  weather,  or  terrain  limitations. 

f.  Navigation  system  selected  has  minimum  impact  on  vehicle 
structure. 

g.  Minimum  size,  weight,  and  power  requirement. 

h.  Possess  high  availability,  reliability,  and  maintainability. 

i.  Low  cost. 

2.  7  RPV  COMMUNICATION  SUboYSTEM 
2.  7.  1  Introduction  and  Summary 

The  system  operational  concept  envisions  the  use  of  airborne  relays  as  an 
element  in  the  communications  system  for  RPVs. 

The  three  dimensional  geometry  of  RPV(s)  and  Relay(s),  together  with  their 
antenna  gain/diroctivity  characteristics,  establish  the  basis  for  path  loss  and 
jamming  vulnerability  analyses.  These  are  discussed  in  Subsection  3.3.4, 
"Communication  Relay  Planning"  and  in  Subsection  3.3.5,  "Integrated  Commu¬ 
nications  Relay  Flight  Profile  Planning." 
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Two  categories  of  communication  links  are  required,  1)  RPV  Control,  i.  e. , 
command  at,d  response  links,  and  2)  the  RPV  sensor  data  link.  The  latter 
normally  requires  10-100  times  the  bandwidth  of  the  first,  although  it  is  likely 
that  control  iteration  rates  will  increase  considerable  over  the  target  area. 

Specific  system  requirements  tend  to  force  the  use  of  UHF  or  microwave 
frequencies  and  line  of  sight  (LOS)  transmission..  The  system  operational 
concept  requires:  1)  small  highly  directive  antennas,  2)  relatively  high  infor¬ 
mation  capacity,  at  least  of  the  RPV  to  relay  link  for  sensor  data,  and3>fre- 
quency  spectrum  availability.  One  non  LOS  possibility  does  exist,  however, 
and  that  is  the  use  of  an  HF  command  link  for  the  enroute  and  return  portions 
of  the  mission.  The  use  of  HF  for  this  function  is  discussed  later  principally 
as  an  item  for  further  study. 

The  most  severe  communication  problems  are:  1)  providing  adequate  antijam¬ 
ming  margin  for  the  RPV  sensor  to  relay  aircraft  link,  especially  if  wide  band 
analog  information  is  transmitted  directly,  2)  controlling  highly  directive  anten¬ 
nas,  and  3)  minimizing  size,  weight,  and  cost  of  RPV  communication  equipment. 

In  summary,  it  appears  that  the  most  desirable  system  has  the  following 
characteristics: 

a.  The  control  link  is  also  used  for  range  measurement.* 

b.  The  relay  uses  a  steerable,  highly  directive  antenna  to  receive 
sensor  data.  Both  this  antenna  and  the  RPVs  antenna  are  also 
used  for  control  purposes  when  over  the  target  area. 

c.  The  RPV  antenna  may  be  similar  to  ;hat  of  the  relay's,  out 
lower  directivity  would  be  acceptable  during  the  enroute  phase. 

d.  For  economy,  RPV  con'. munlcation  and  radar  terrain  following 
(TF)  equipment  are  designed  for  maximum  commonality,  e.g.  , 
they  use  the  same  type  of  antenna,  and  perhaps  R-T  and  power 
supply  assemblies  for  both  functions. 

e.  The  relay  should  employ  Interference  Cancellation  System  (ICS) 
techniques  for  ECCM  as  discussed  in  Subsection  2.7.8. 

Various  alternative  approaches  can  be  considered,  however  most  are  asso¬ 
ciated  with  antenna  selection,  frequency  of  operation,  and  ECCM. 

Following  paragraphs  describe  these  links  (initially  assuming  no  ECM)  and 
consider  first  those  aspects  which  are  common  to  both  link  categories,  then 
ECM  vulnerability  is  considered,  potential  ECCM  approaches  are  discussed, 
and  finally,  areas  for  further  investigation  are  suggested. 


*This  is  an  alternative  means  of  navigation,  or  actually  RPV  position  deter¬ 
mination.  Other  approaches  to  this  functional  requirement  are  mentioned  in 
Subsection  2.  6,  "RPV  Navigation  System.  " 
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2.7.2  Optimum  Geometry  of  Relay(s)  Relative  to  RPV(8) 


It  is  assumed  that  line  of  sight  (LOS)  transmission  is  required  and  that  it 
exists  continuously  during  the  mission  execution  phase.  Possible  brief  signal 
interruptions  due  to  non  LOS  geometry  are  assumed  enroute  to  the  target  area 
and  on  return  to  base. 

As  is  the  case  with  satellite  relays ,  it  is  the  up-link  which  is  vulnerable  to 
jamming  because  of  the  jammers  difficulty  in  physically  locating  himself  to 
intercept  the  down-link  receiving  beam  (see  Figure  2.7-1).  Two  up-link 
transmission  paths  exist;  1)  the  link  from  control  station  to  the  relay,  and 
2)  RPV  response  and  sensor  data  up-links  to  the  relay.  The  first  is  relatively 
invulnerable  because  the  jammer  must  compete  with  the  ground  station's  high 
Effective  Isotropic  Radiated  Power  (EIRP),  a  term  which  includes  both  trans¬ 
mitter  output  power  and  antenna  gain.  Also,  it  i9  unlikely  that  a  jammer  will 
be  physically  located  on  the  friendly  side  of  the  FEBA,  hence  the  relay  anten¬ 
na's  directivity  also  works  against  him.  Finally,  the  relatively  low  informa¬ 
tion  rate  of  the  command  links  greatly  ease  the  A/J  signal  design  problem 
(compared  to  RPV  sensor  up -links). 

Since  the  RPV's  up-link  power  and  antenna  gain  (EIRP)  are  more  likely  to  be 
limited  than  that  of  the  relay,  it  is  obvious  that  the  up-link  receiving  antenna 
for  RPV  sensor  data  should  have  the  highest  practical  gain.  This  means  that 
unless  the  jammer's  physical  location  is  such  that  he  can  intercept  the  beam 
he  will  suffer  a  commensurate  power  disadvantage.  Tactically  then,  jammers 
should  be  located  near  potential  targets  within  the  half-beam  width  of  the  re¬ 
lay's  sensor  receiving  antenna.  Figure  2.  7-1  illustrates  this  since  only  the 
'‘best**  jammer  location  allows  him  to  jam  the  main  beam  while  RPV  1  is  over 
target  No.  1.  The  jammer  will  know  which  direction  to  aim  hia  antenna  (impor¬ 
tant  unless  the  jammer  can  be  successful  with  a  horizontal  beam  approaching 
90  degrees)  only  if  commands  also  emanate -from  the  same  point.  This  can  be 
avoided  by  using  two  relay  aircraft,  one  for  enroute  commands  and  another 
for  sensor  data,  when  RPVs  are  attacking  targets.  Two  identical  relay  air¬ 
craft  can  exchange  control  responsibility  periodically,  oi  course.  Minimum 
(3  dB),  »30  dB  gain,  beam  widths  (”0"  in  Figure  2.7-1)  approximate  five  deg¬ 
rees  assuming  typical  steerable  parabolic  dishes  of  about  one  foot  in  diameter 
operating  in  the  15  GHz  region  of  K  band.  Thie  is  probably  an  upper  frequency 
limit  for  communication  links  due  to  weather  effects.  Design  assumptions 
were  based  on  the  eight-inch  dish  of  the  APQ-1 10  TF  radar. 

Table  II,  7-1  lists  the  kinds  of  antennas  which  probably  should  be  considered 
at  the  various  locations.  Where  directive  antennas  are  used  for  enroute  func¬ 
tions  some  means  of  pointing  them  correctly  is  required.  At  the  relay  the/ 
must  be  re-directed  from  one  RPV  to  another  at  a  reasonable  update  rate. 

For  the  five  degree  beam  width  case  half  the  distance  subtended  is  approxi¬ 
mately  four  miles  at  100  mile  range.  Hence,  two  aircraft,  flying  in  opposite 
directions  at  right  angles  to  the  beam  will  approach  the  beam's  edge  in  approx¬ 
imately  12  seconds.  Since  up-date  rates  are  assumed  shorter,  antenna  re- 
pointing  will  not  be  required  at  the  RPV  as  long  as  it  uses  an  automatic  track¬ 
ing  antenna.  The  same  antenna,  if  used  at  the  relay,  must  be  repointed  for 
each  RPV  interrogated  but  pointing  angles  would  not  need  to  be  recomputed 
each  time.  Only  the  "last  used"  settings  would  need  to  be  stored  in  memory 
for  each  RPV,  again  assuming  auto  track  operation. 
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of  Rela 


Table  II.  7-1.  Antenna  Types  Considered 


Location  and  Purpose 

Control  Link 

Sensor  Data 

r  „  > 

Potential  Use 

of  Antenna 

Response 

Up-Link 

for  Navigation 

OnRPVs 

Enroute  Phase 

! 

Transmit  on  F2 

DMA 

| 

Omni,  sector, 
or  steerable 
dish 

Notin  use 

Yes 

Receive  on  Fl 

Omni,  sector 
or  steerable 
dish 

DNA 

DNA 

Yes 

HF  Receive  on  F3 

Horizontally 

polarized 

loop 

DNA 

DNA 

? 

Over  Target  Phase 

Transmit  on  F2 

DNA 

Steerable  dish 

Steerable  dish 

No 

and  F4 

(required) 

Receive  on  FI 

Steerable  dish 

DNA 

DNA 

No 

HF  Receive  on  F3 

loop  (if  HF 
is  used  here) 

DNA 

DNA 

No 

ON  RELAY  A/C 

Enroute  Phase 

Transmit  on  FI 

Omni  sector, 
phased  array, 
or  azimuth 

DNA 

DNA 

Yes 

scantier 

Receive  on  F2 

DNA 

Omni,  sector, 
phased  array 
or  azimuth 

Not  in  use 

Yes 

tanner 

Over  Target  Ptuse 

Transmit  on  FI 

1  One  steerable  dish  per  RPV  or  a  phased  srrsy  with  one 

No 

and  receive  on 

phase  shifter  assembly  per  RPV 

F2andF4 

1 

t 

AT  GROUND  STATION 

Transmit 

' 

Steerable  dish 
per  relay  A/C 

DNA 

DNA 

Yes 

Receive 

DttA 

Steerable  dish 

Steerable  dish 

Yes 

per  relay  A/C 

per  relay  A/C 

HF  Transmit  on  F3 

Horizontal 

dipole 

DNA 

DNA 

Yes 

Table  XI.  7-1  Indicates  that  a  steerable  dish,  or  equivalent  array,  is  required 
on  the  RPV  because  of  the  critical  sensor  wide -band  data  up-link.  To  save 
weight  and  space  it  should  also  be  used  for  all  other  functions.  It  can  be 
steered  or  pointed  to  the  relay  A/C  by  automatic  tracking  equipment,  and 
thus  be  independent  of  navigation  functions. 

Relay  station  antenna  choices  are  not  so  clear  cut.  Control  during  the  enroute 
phase  would  be  most  desirable  via  an  omnidirectional  antenna  since  this  would 
avoid  the  repositioning  associated  with  a  directive  antenna  and  multiple  RPVs. 
Sector  antennas  substitute  switching  for  pointing,  and  are  therefore  also  a 
reasonable  choice.  The  azimuth  scanner  operates  like  an  IFF  system  in  that 
it  controls  each  RPV  while  the  beam  impinges  on  it.  If  this  antenna's  scans 
are  accurately  controlled  and  stabilized  relative  to  true  North  the  time  delay 
from  a  reference  pulse  indicates  the  RPV's  angular  relative  bearing  in  a 
manner  equivalent  to  the  omnirange. 

If  none  of  the  above  approaches  are  practical  and  substantial  directivity  is 
required  for  control  it  appears  that  a  phased  array  must  be  used  because  of 
the  scan  rate  limitations  of  mechanically  positioned  antennas. 

Over  the  target  one  steerable  dish  per  RPV  is  adequate  since  rates  of  change 
of  angle  are  limited,  A  phased  receiving  array  might  be  advantageous  in  that 
a  single  array  could  operate  with  several  RPVs  as  long  as  an  independent 
phase  shift  assembly  was  provided  for  each. 

Ground  station  antennas  do  not  seem  to  be  a  problem,  their  choice  probably 
being  based  on  minimizing  relay  A/C  cost. 

2.7.3  Operational  Considerations  Relative  to  Communication 

If  we  assume  that  the  enemy  will  make  a  concerted  attempt  to  jam  the  RPV 
communications,  both  operational  and  technical  factors  must  be  considered 
if  this  threat  is  to  be  counteracted  most  effectively.  The  latter  aspect,  dis¬ 
cussed  in  the  following  sections,  involves  such  things  as  transmitter  power, 
antenna  gain,  modulation  techniques,  etc. 

Operationally  the  utilization  of  any  relationships  with  other  tactical  systems, 
as  well  as  own  system  tactics  can  be  of  value.  Further,  several  aspects  need 
to  be  considered  prior  to  the  establishment  of  the  total  systems  technical 
approach.  Some  necessary  assumptions  must  be  made  in  response  to  the 
following  questions: 

a.  What  does  the  jammer  know? 

Assumptions: 

1.  From  a  priori  knowledge  he  knows: 

All  details  of  our  equipment  such  as  frequency  range, 
antenna  characteristics,  power,  method  and  details  of 
multiplexing,  ECCM  provisions,  etc.  (Effectively,  he  buys 
one  complete  set  from  the  US  factory  complete  with  all 
documentation.) 


2.  From  field  operations  he  learns; 

•  Transmitter  frequencies  of  relays  with  some  delay 
required  for  signal  acquisition;  the  delay  increasing 
with  relay  antenna  directivity. 

«  RPV  transmitter  frequencies  with  a  greater  delay. 

e  Transmitter  frequencies  at  ground  control  stations; 
if  he  needs  to  know. 

a  Identity  of  relays  because  of  their  fliglt  profile  and  , 
behind  FEBA  location,  EM  signature,  etc. 

b.  What  doesn't  the  jammer  know? 

Assumptions: 

1.  He  doesn't  know  which  targets  will  be  attacked  until  very 
late  in  mission  time  as  attack  break-off  and  deliberate 
feints  are  very  likely. 

2.  Which  portion  of  a  command  data  stream  is  intended  for 
a  particular  RPV. 

3.  Which  relay  is  controlling  &  particular  RPV  if  more  than 
one  is  present. 

4.  The  effectivity  of  his  jamming  except  in  &  gross  sense. 

c.  What  tactics  are  available  to  enemy  other  than  EW  ? 
Assumptions* 

1.  He  may  send  missile(s)  or  manned  interceptors )  to  destroy 

relays. 

2.  Use  missiles  which  home  on  RPVs  if  their  transmitted 
signal  characteristics  permit. 

3*  Attempt  to  destroy  the  ground  control  station  or  launching 
facilities. 

d.  What  tactics  are  available  to  the  Relays? 

Assumptions: 

1,  Change  location  in  real  time. 

2,  If  there  are  at  least  two  relay  A/C,  reallocate  communi¬ 
cations  responsibility  periodically. 
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3.  Trade  information  transfer  rate  for  A/J  protection: 

•  Enroute  -  reduce  interrogation  rate. 

•  Over  the  target  -  reduce  video  up-linh  data  rate. 

Other  tactical  considerations  relate  to  the  possibility  of  cooperation  between 
relays  of  different  groups  of  the  total  force;  e.  g. ,  reallocation  of  responsi- 
bility  for  control  of  specific  RPVs  to  deny  the  enemy  consistent  means  of 
relating  an  attacking  RPV  to  its  control  source.  Planning  activities  can  also 
be  directed  towards  minimization  of  the  ECM  threat  as  discussed  in  Subsec  - 
tion  3. 3. 6,  "Communications  Relay  Planning. " 

2.7.4  RPV  Sensor  Data  Link 

Most  generally,  a  TV  picture  or  some  other  scanned  image  is  being  trans¬ 
mitted  from  the  target  area  to  the  relay.  This  information  can  be  either  in 
analog  or  digital  form.  This  link  is  the  most  critical  one  of  all  RPV  com¬ 
munications  links  since  it  must  transmit  wide -band  information  and,  due  to 
the  geometric  arrangement  discussed  in  Subsection  2.7.2,  is  the  most  easily 
jammed.  Since  its  output  is  essential  to  the  most  critical  phase  of  the  mis¬ 
sion  it  would  appear  to  be  the  most  logical  place  to  expect  ECM. 

Jamming  resistance  can  be  improved  most  readily  for  low  rate  digital  trans¬ 
missions,  although  the  Interference  Cancellation  System  (ICS)  is  applicable 
to  analog  signal  transmission  in  some  instances,  as  is  discussed  in  Subsec¬ 
tion  2.  7.7.  Wide-band  information  links,  however,  are  more  difficult  to  pro¬ 
tect  from  jamming  since  spread  spectrum  approaches  inevitably  increase  the 
occupied  bandwidth  by  several  orders  of  magnitude;  e.g, ,  5  Mhz  becomes 
50  MHz  for  only  10  dB  A/J  margin  thus  further  complicating  synchronization, 
etc. 

One  aspect  of  the  data's  nature  that  does  help  is  that  it  is  generally  redundant, 
hence  loss  of  some  percentage  of  the  transmitted  "frames"  can  be  tolerated. 
Thus  one  might  perform  integration  of  successive  frames/ scans  to  improve 
SNR  or  perhaps  shift  to  another  frequency  slot  whenever  jamming  is  detected. 
If  done  in  a  pseudo  random  manner  this  can  be  fairly  effective  approach  with¬ 
out  introducing  excessive  complication;  as  long  as  a  command  link  is  available 
to  initiate  the  frequency  shifts. 

The  most  elegant  approach  of  course  is  to  reduce  the  transmitted  data  rate 
through  redundancy  elimination  processes.  However,  such  approaches  are 
outside  the  scope  of  this  study. 

At  the  target,  RPVs  will  have  no  range  advantage  over  the  jammer;  hence 
they  should  use  a  steerable  highly  directive  antenna  to  increase  their  signal 
level  relative  to  a  ground  based  jammer  which  has  no  size  and  weight  limita¬ 
tions.  Also  the  same  antennas,  and  perhaps  the  same  R-T  equipment,  via 
multiplexing,  should  be  used  for  "over-the-target"  control.  Since  control 
data  rates  are  lower  than  sensor  output  rates  they  can  be  easily  provided  with 
additional  A/J  margin  to  insure  reliability  of  control  functions. 
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Some  of  these  aspects  were  discussed  previously  in  connection  with  antenna 
selection  in  Subsection  1.7*1. 


2.  1,  5  RPV  Command  and  Response  Links 

Initially  the  operational  aspects  of  this  function  are  considered.  The  assump¬ 
tion  is  that  a  given  control  station  will  be  responsible  for  multiple  (up  to  25) 
RPVs  for  both  the  enroute  and  on-target  phases  respectively  of  each  RPV's 
mission.  ft  is  also  assumed  that  control  transmissions  are  digital  and  may 
be  discontinuous i  i.e.,  enroute  and  RTB  the  RPVs  can  fly  and  navigate  them¬ 
selves  automatically  with  only  occasional  corrections. 

The  jammer  must  be  prevented  from  either  controlling  the  RPV  himself  or 
from  precluding  our  control.  The  former  is  easy  since  spoofing  can  be  abso¬ 
lutely  prevented  by  cryptographic  techniques  which  for  the  latter  can  be  sim¬ 
ply  extended  to  provide  an  appropriate  A/J  margin.  It  might  be  desirable  if 
the  A/J  margin  was  made  sufficient  to  allow  the  use  as  an  omnidirectional 
antenna,  at  least  for  the  command  down -link. 

Since  multiple  RPVs  are  assumed,  three  means  of  establishing  a  command 
link  to  each  can  be  considered.  These  are;  1)  assign  a  separate  link  to  each, 

2)  use  a  multiplexed  single  link  (FDM  or  TDM),  or  3)  use  a  single  link  witha 
separate  address  for  each  RPV.  Combinations  of  these  can,  of  course,  also 
be  surmised. 

Response  links  could  be  handled  similarly  except  that  self  interference 
between  RPV  responses  must  either  be  prevented  absolutely  or  be  of  ade¬ 
quately  low  probability. 

The  simplest  approach  appears  obvious,  i.e.,  associate  a  given  RPV's  re¬ 
sponse  with  the  command  causing  it  to  respond.  Since  we  have  assumed  that 
cryptographic  security  U  required,  each  RPV  either  has  his  time  clock  syn¬ 
chronised  with  the  other  RPVs,  or  is  brought  into  crypto  sync  periodically  by 
means  of  a  preamble.  To  maximize  efficiency  the  frequency  of  command 
transmissions  must  be  considered  since  the  preamble  is  either  equivalent  to 
an  address  or  must  be  followed  by  an  address.  The  first  implies  a  separate 
crypto  key  setting  for  each  RPV  while  the  latter  assumes  the  same  setting 
for  all. 

The  simplest  approach  appears  to  be  the  use  of  a  common  key  with  RPVs 
assigned  unique  time  slots  (equivalent  to  addresses)  in  a  repetitious  frame 
structure.  The  relay  aircraft  then  transmits  continuously,  or  at  least  period¬ 
ically,  which  maintains  sync  at  the  RPVs,  and  each  RPV  responds  in  another 
unique  time  slot  either  periodically  or  only  in  response  to  command  receipt. 
These  RPV  responses  can  thus  use;  1)  the  same  frequency  (time  slots 
reserved  for  responses),  2)  a  different  frequency  in  the  same  band,  or 

3)  perhaps  use  his  sensor  up-link  frequency.  The  latter  would  seem  practical 
only  during  the  execution  phase  hence  either  1)  or  2)  must  be  provided  in 
addition. 
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The  encrypted,  time  slotted  TDM  approach  appears  to  provide  the  least 
information  to  the  jammer  since  all  that  he  can  distinguish  may  be  the  exist¬ 
ence  of  a  given  RPV's  responses  through  radiated  energy  measurement. 

Time  slot  assignments  could  also  be  varied  in  a  pseudo  random  manner  to 
prevent  him  from  burst  jamming  either  commands  or  a  RPV's  response  time 
slot  from  a  priori  knowledge  of  frame  length,  etc.  Randomly  occurring  re¬ 
sponses  from  several  RPVs  would  seem  to  make  DF  or  homing  quite  difficult 
unless  the  angular  differential  between  RPVs  and  the  jammer's  intercept 
receiver  are  quite  large. 

If  desirable,  the  command  message  structure  could  also  be  varied  such  that 
an  RPV  would  respond  only  when  directed  to  do  so. 

One  aspect  of  continuous,  periodic,  or  even  of  relatively  long  duration  com¬ 
mand  transmissions  is  that  a  radiation  seeking  missile  could  be  used  to 
destroy  the  source  of  command  transmissions  just  as  an  anti-radar  missile 
can  easily  destroy  any  radar  not  taking  appropriate  counter -action.  This 
aspect  requires  further  study  but  appears  to  indicate  the  use  of  different  fre¬ 
quency  bands  for  the  enroute  and  over  the  target  phases.  Also  multiple  relay 
A/C,  with  periodic  transfer  of  function  would  provide  more  security  against 
this  form  of  attack.  Directional  antennas  on  relay  A/C  appear  of  value  also, 
for  this,  as  well  as  ECCM  reasons. 

2.  7. 6  Selection  of  RPV  Communication  Equipment 

Since  coBt  of  RPVs  must  be  minimized  the  possibility  of  combining  the  func¬ 
tions  of  navigation,  flight  control  and  communication  in  one  set  of  equipment 
should  be  considered.  If  one  assumes  that  an  RPVs  equipment  must,  as  a 
minimum,  include;  1}  an  autopilot  for  course  and  attitude  stabilization,  and 
2)  control  (command  and  response)  and  sensor  data  links,  what  approaches 
to  RPV  navigation  will  minimize  the  cost? 

Five  possible  methods  of  measuring  an  RPV's  position  are; 

a.  Inertial  (rejected  as  being  too  expensive). 

b.  LORAN 

c.  Radio  ranging  from  relay  (requires  two  relay  positions  to 
determine  RPV  position). 

d.  NAVSAT  (rejected  because  it  takes  too  long  between  fixes), 

e.  TACAN,  etc. 

Of  the  above  only  c.  is  potentially  combinable  with  the  relay  to  RPV  commu¬ 
nication  function.  All  others  will  require  extra  RPV  equipment.  Ranging 
from  the  relay  itself  also  does  not  require  any  other  navigation  equipment  or 
aids  in  the  area  of  operations.  However,  the  command  and  response  links 
wilt  need  to  be  appropriately  modulated  in  order  to  sense  range  unambig¬ 
uously.  There  are  several  means  of  doing  this  from  using  psuedo -noise 
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sequences  to  simply  counting  doppler  cycles.  Since  the  latter  requires 
continuous  reception  the  former  appears  more  practical  and  also  more 
consistent  with  providing  security  and  ECCM. 

It  might  also  be  possible  to  combine  the  terrain  following  radar  function  with 
the  command  and  response  links  since  time  multiplexed  operation  is  assumed. 
R-T  equipment  would  thereby  be  reduced,  however  separate  antenna (s)  would 
be  essential  for  the  radar  terrain  follower  -  altimeter  portion.  This  Is  an 
area  requiring  further  study  and  may  not  be  feasible  due  to  differences  in 
optimum  operating  frequencies. 

Figure  2.  7-2  is  a  block  diagram  of  RPV  equipment  assuming  the  use  of 
shared  equipment  as  discussed  above.  As  discussed  in  Section  2.  7.  2,  a 
steerable  dish  appears  to  be  a  requirement,  considering  the  ECM  threat. 

This  antenna  must  be  continuously  pointed  at  the  relay  A/C  and  this  can  be 
easily  accomplished  by  automatic  tracking  of  control  transmissions  without 
requiring  coupling  to  the  RPV'a  autopilot.  Ideally,  two  identical  antenna 
assemblies  might  be  used;  one  forward  for  terrain  following,  and  one  aft  for 
communication. 

2.  7.  7  Description  of  Relay  Station  Equipment 

It  is  not  the  purpose  of  this  tudy  to  describe  in  detail  the  various  items  of 
communication  equipment  on  either  the  relay  or  RPV.  Rather,  several  vari¬ 
ations  in  approach  have  been  suggested  in  the  interest  of  minimum  RPV  pro¬ 
duction  cost,  minimum  ground  navigation  aids,  etc.  However,  these  varia¬ 
tions  may  imply  expense  in  terms  of  relay  complexity. 

Figure  1.6-2  of  Section  1  indicated  the  major  functions  required  at  the  relay. 
Antenna(s)  sUe  depends  on  transmitter  power  output  and  data  rate  as  is  usual, 
however  at  the  relay,  greater  directivity  (and  power  gain)  might  be  used  for 
improved  ECCM.  Antenna  considerations  were  discussed  in  Subsection  2.7.2, 
together  with  various  means  for  controlling  or  pointing  each  type, 

On  board  communication  data  processing  may  involve  antenna  pointing  compu¬ 
tations  or  navigation  algorithms;  e.g.,  for  a  LORA N- Inertial  system.  Proc¬ 
essing  tasks  on  board  the  relay  may  be  increased  to  minimize  either  the 
amount  of  data  exchanged,  or  the  frequency  of  command  transmissions,  or 
perhaps  reduced  in  favor  of  similar  operations  at  the  ground  control  station, 
etd. 

Naturally,  there  will  be  many  items  of  electronic  equipment  on  board  the 
relay  aircraft  which  are  not  directly  associated  with  the  RPV  mission, 

Included  are  such  things  as  radar  altimeters,  navigation  aids,  radio  R-T  units, 
etc*  Some  of  these  might  be  useful  or  ancillary  to  RPV  operations  but  are 
not  subject  to  discussion  here. 

2.  7. 8  ECM  Vulnerability  Considerations 

*  mu jf  m  wml— mu  — mm 

Often  data  links  are  initially  designed  to  provide  adequate  performance  con¬ 
sidering  only  natural  phenomena.  Inevitably  EW  considerations  will  impact 
both  hardware  and  operational  aspects. 

- Izlb 


Functional  Block  Diagram,  Relay/RPV  COMM/Ranging  Equipment 


Assuming  that  some  form  of  spread  spectrum  approach  is  used  to  provide 
A/J  margin  the  following  changes  are  likely: 

a.  For  digital  systems,  internal  clock  rates  and  RF  bandwidth 
will  increase  by  the  gross  A/J  margin;  e.g. ,  by  103  for  30  dB 
etc.  Where  crypto  security  is  already  included,  the  impact  is 
primarily  one  of  increasing  synchronization  accuracy  require¬ 
ments.  For  frequency  hop  schemes,  frequency  synthesizer 
complexity  will  increase. 

b.  For  analog  systems  perhaps  the  only  measures  available  are 
increased  power,  or  antenna  directivity,  or  changes  in  the  mode 
of  operation.  One  other  possibility,  applicable  to  either  analog 
or  digital  transmission,  is  the  Interference  Cancellation  System 
(ICS)  which  is  discussed  in  the  final  paragraph  of  this  section. 

c.  Signal  acquisition  times  will  probably  increase  due  either  to 
requirements  for  tighter  sync,  or  sharper  antenna  directivity, 
or  both. 

d.  Reliability  and  Maintainability  can  be  expected  to  decrease  with 
the  increased  number  of  parts,  etc. 

e.  Possibly  on  board  data  processing  requirements  will  increase 
to  support  c.  above. 

Anti-jamming  tactics  which  might  be  employed  are;  1)  the  use  of  additional 
relays  as  discussed  in  Subsection  2.  7.  2,  or  perhaps  also  additional  RPVs, 

2)  direct  physical  attack  on  the  jammers  themselves  by  radiation  seeking 
missiles  (a  special  RPV),  3)  periodic  coordinated  shifts  in  operating  fre¬ 
quency,  whose  offectivity  will  depend  on  the  enemy's  reaction  time,  and 
4)  combinations  of  1)  and  3)  such  that  the  jammer  cannot  concentrate  on  a 
single  relay/RPV  combination. 

Other  effects  such  as  planning  impacts  are  discussed  in  Subsection  3.3.  5. 

2.7. 8.1  Automatic  Interference  Cancellation  (AIC) 

The  block  diagram  in  Figure  2.7-3  illustrates  the  essentials  of  interfering 
signal  cancellation  for  the  two  casos;  1)  a  colocated  "friendly"  (Connection  A) 
transmitter,  and  2)  an  example  of  one  approach  to  the  cancellation  of  a  jam¬ 
ming  signal  (Connection  B).  More  than  one  signal  can  bo  cancelled  if  a  servo 
mechanism  and  reference  signal  is  specifically  provided  for  each.  The  FAA 
uses  a  system  which  protects  a  receiver  from  up  to  four  fixed-tuned  local 
transmitters;  all  sharing  the  same  antenna.  Automatic  systems  with  servos 
can  track  varying  frequency  interference,  having  aribtrary  modulation 
characteristics  and  wide  bandwidth. 

The  principle  is  exceedingly  simple;  merely  adjust  the  level  and  time  delay 
(RF  phase)  of  the  interference  reference  to  equality  with  the  interference 
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actually  received  so  that  it  can  be  subtracted  from  the  receiver's  composite 
input.  The  servo  does  this  automatically  for  any  signal  type  through  auto¬ 
correlation,  Note  that  a  signal  '“path"  is  being  simulated,  and  not  the  inter¬ 
fering  signal  itself.  A  range  of  60-80  dB  of  cancellation  is  possible  in  a 
practical  case,  as  long  as  ths  interference  does  not  vary  its  spatial  position 
more  rapidly  than  the  servo  can  follow.  This  is  unlikely  in  most  instances. 

Extension  to  EW  requires  chat  the  jammer  signal  exceed  the  noise  level  and 
be  stronger  than  the  desired  signal  in  order  for  the  autocorrelator  to  control 
the  se:  /o.  Hence,  at  "Connection  B"  the  jammer  is  "enhanced",  relative  to 
signal,  by  steering  the  antemia"s  null  toward  the  desired  signal's  direction. 
Note  that  the  conventional  antenna  nulling  techniques  attempt  to  achieve  null 
against  an  uncooperative  "target"  (the  jammer)  and  also  that  multiple  "nullers" 
are  required  for  multiple  jammers.  Other  approaches  are  possible,  for  ex¬ 
ample,  a  low  order  of  spectrum  spreading  (<  10  dB)  should  suffice  without 
requiring  the  use  of  separate  receiver  and  jammer  reference  antennas. 

The  advantages  of  Automatic  Interference  Cancellation  (AIC)  for  EW  include 
the  following: 


a.  Provides  >60  dB  A/J  which  exceeds  that  possible  with 
spread-spectrum  schemes. 

a.  Operable  with  analog  signals  such  as  TV  or  other  "scanning" 
devices. 

c.  Introduces  no  additional  sync  problems. 

d.  Can  be  added  "in  front"  of  existing  radios,  analog  or  digital. 

The  AIC  approach  described  above  as  an  example  is  not  directly  applicable  to 
the  RPV-to-relay  link  where  jammers  are  colocated  with  targets.  The  basic 
requirement  is  to  obtain  a  reference  jammer  signal  which  either  does  not 
include  the  desired  signal  at  all  or  only  at  a  level  negligible  compared  to  the 
jammer's  Level.  Negligible  in  this  case  might  be  only  -2  dB, 

One  cannot  assume  that  the  jammer  will  cooperate  by  using  excessive  power, 
however,  this  relative  level  is  not  easily  determined  remotely.  An  RPV's 
signal  level  will  presumably  decrease  as  it  approaches  the  target  (due  to  an 
increase  in  range).  It  could  also  be  controlled  via  the  command  link  if  this 
were  an  appropriate  tactic.  Also,  the  RPV  signal  can  be  made  intermittent 
on  command,  hence  it  appears  easy  to  obtain  the  jamming  signal  alone. 

To  summarize  —  ICS  appears  to  be  worthy  of  serious  consideration  for  the 
RPV-to-reiay  sensor  up-link.  Should  this  be  a  digital  link  it  appears  that 
about  10  dB  A/J  margin  would  be  sufficient  with  ICS  and  the  resultant 
complexity  is  small. 
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2.  7.  9  Areas  for  Further  Investigation 


Several  areas  appear  worthy  of  further  study,  some  being  related  to  technol- 
iod  others  to  cost  minimization.  Previous  subsections  have  suggested 
alternate  approaches,  as  in  Subsection  2.  7.6  where  a  single  frequency  band 
and  set  of  RF  hardware  was  proposed  for  command  reception,  response  trans 
mission,  for  both  functions  of  a  terrain  following  radar,  and  for  a  range  meas 
uring  link.  Separate  antennas  would,  of  course,  be  required  for  the  terrain 
follower.  This  particular  suggestion  is  a  complex  one  to  analyze,  involving 
both  systems  performance  and  hardware  cost  trade-offs. 

The  new  use  of  the  command  and  response  links  for  RPV  range  measurement 
definitely  appears  worthwhile  and  might  be  considered  a  minimum  objective 
because  the  measurement  of  RPV  range  directly  from  the  relay  provides  sub¬ 
stantial  advantages.  One  range  does  not  determine  position  of  course,  hence 
two  measurements  from  two  known  relay  positions,  either  for  two  separate 
A/C,  or  two  different  positions  of  the  same  A/C,  are  needed.  Depending  on 
the  relay  antenna  used,  it  may  also  be  possible  to  measure  angles  to  estab¬ 
lish  RPV  position. 

The  use  of  HF  for  a  one-way  command  link  directly  from  a  ground  statlon(a) 
to  all  RPVs  has  also  been  suggested.  The  low  data  rate  makes  this  non-line- 
of-sight  transmission  mode  practical,  provided  that  horizontally  polarized 
antennas  are  used,  since  these  emphasize  the  ionospheric  path  for  all  dis¬ 
tances  under  consideration.  However,  only  one-way  operation  can  be  ser¬ 
iously  considered  because  the  only  practical  horizontally  polarized  HF  antenna 
for  RPVs  is  a  loop  which,  because  of  low  efficiency.-  is  only  suitable  for 
reception.  Such  a  link  could  also  be  employed  to  measure  time,  hence 
approximately  range,  for  transmission  from  the  ground  station  to  a  particular 
RPV  and  back  to  the  relay  A/C  via  the  LOS  command  response  up-link.  The 
relay  A/C  would  know  the  time  of  arrival  of  the  direct  HF  signal  and  the  sum 
of  the  transmission  time  to  the  RPV  and  the  time  delay  on  the  RPV  to  relay 
up-link.  Since  he  already  knows  the  latter,  he  knows  three  sides  of  a  triangle 
and  can  solve  for  the  RPV*  a  position  unambiguously. 

The  time  delay  on  the  HF  link  is  not  directly  proportional  to  range  because  of 
ionospheric  reflection,  however  corrections  can  be  entered  through  data  proc¬ 
essing  either  on  the  ground  or  perhaps  at  the  relay. 

Resulting  errors  appear  to  approximate  a  small  fraction  of  a  millisecond, 
hence,  the  usefulness  of  this  function  may  be  partially  dependent  on  geometry 
as  errors  along  a  chosen  course  may  be  less  significant  than  equal  cross- 

range  uncertainty.  Obviously,  further  study  of  the  accuracy  attainable  is 
necessary. 

The  use  of  highly  directive  antenna  on  the  relay  will  require  correspondingly 
high  pointing  accuracy.  If  rapid  switching  between  RPVs  becomes  necessary, 
a  phased  array  might  become  an  absolute  requirement.  Study  of  the  data 
processing  impact  for  a  given  pointing  requirement  seems  essential.  Also, 
pointing  computations  would  appear  much  easier  if  the  antenna  is  placed  in  an 
automatic  tracking  mode  when  close  to  the  correct  angle. 
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SECTION  3 


DRONE/RFV  COMMAND  AND  CONTROL 


3. 1  DEFINITION  OF  COMMAND  CONTROL  FUNCTIONS 

There  are  two  different  cspects  of  RFV  command  and  control.  One,  physical 
control,  insures  that  the  vehicle  executes  the  specific  planned  mission.  The 
second  aspect,  force  control,  insures  that  RPV  as  a  weapon  system  is  used, 
alone  or  in  coordination  with  manned  missions,  to  achieve  force  objectives. 
Table  III.  1-1,  tabulates  the  Command  and  Control  Functions  under  these  two 
broad  titles.  These  functions  are  derived  from  the  comparable  functions  for 
manual  systems. 

Table  III,  1-1.  Dr one/RPV  1st  Level  Command  and  Control  Functions 


Mission  Planning 
Preplanned 
Missions 

Mission  Monitoring, 
Immediate  Mission 
Planning,  Replanning 
and  Adjustment 

Physical  Control 

Mission  Require¬ 
ments  Analysis 

Resource  Analysis 

Resource  Status 

Monitoring 

Launch 

Apportionment 

Mission  Execution 

Enroute  Control 

Monitoring 

Unit  Assignment 

Mission  Adjustment 

Over  the  Target 

Detailed  Mission 

Direction 

Control  (Strike) 

Planning 

Mi s  slon  Replanning 

•  Target  Penetration 

•  Over -the 

Target  Opera- 

e  Men  Reqmts  Anal. 

•  Target  Acquisition 

tiqne  '(Strike) 

a  On  Station 
Operations 
(EW,  RECCE) 

Route  Planning 

Laun  ch  /  Rec  c  very 

Communications 
Relay  Planning 

•  Detailed  Men  Planning 

e  Delivery  Maneuver 

•  Weapon  Release 

•  BDA 

•  Egress  Maneuver 

•  RTB  Control 

•  Recovery  Control 

On  Station  Control 
:  (RECCE  k  EW) 

Subsection  3. 2  documents  the  requirements  for  physical  control  of  the  RPV, 
Where  options  exist,  the  effects  of  viable  alternatives  are  established  or, 
alternatively,  the  assumptions  necessary  £o  select  an  option  are  documented. 
Subsection  3.3,  documents  die  impact  of  RPV  on  the  Force  Control  functions. 
Where  applicable,  the  differences  between  pure  RPV  force  only  and  a  mixed 
force  (including  manned  aircraft)  are  assessed. 

The  interrelationship  between  the  Force  Control  functions,  the  physical  con¬ 
trol  capability,  and  the  RPV  baseline  system  capability  is,  in  some  areas, 
a  very  complex  trade-off  chain.  This  study  adapts  the  system  capability 
developed  under  the  Air  Force  funded  multimission  studies  for  the  RPV 
baseline.  Where  appropriate,  the  impact  of  viable  alternatives  are  assessed. 
From  this  departure  point  the  vehicle  physical  control  requirements  and  im¬ 
plementation  concepts  are  developed.  The  impact  of  these  requirements  on 
detailed  mission  planning  and  other  Force  Control  functions  are  then  assess¬ 
ed,  and  implementation  concepts  at  the  function  level  are  developed.  System 
performance  requirements  are  developed,  assembled,  and  allocated  to  TAGS 
elements  and/or  the  RPV  functional  unit,  and  the  system  configuration  and 
performance  requirements  are  established.  Again,  viable  alternatives  are 
identified.  Figure  3.1-1,  Analysis  Process,  Command  and  Control  for 
RPV' s,  diagrams  the  process. 

3.2  PHYSICAL  CONTROL  OF  RPV'S 

3. 2. 1  Introduction 


It  should  be  stressed  at  the  outset  that  complex  trade-off  analyses  would  be 
necessary  to  justify  a  final  allocation  of  functions  to  air  vehicle  and  ground- 
based  system  elements,  and  to  select  a  specific  method  of  implementing  each 
function, 

Many  of  die  functions  necessary  to  physical  control  of  RPV's  could  be  per¬ 
formed  at  a  ground  control  center,  on-board  the  RPV,  or  on  a  communications 
relay  aircraft.  Examples  of  these  functions  would  include;  RPV  position  de¬ 
termination*  comparison  of  actual  with  planned  flight  profile,  computation  of 
corrections  to  aircraft  flight  control  settings,  determination  of  weapon  re¬ 
lease  point,  etc.  Many  functions  could  be  performed  with  various  degrees 
of  automation;  for  example,  target  recognition  could  bd  performed  by  a 
human  operator  using  remoted  RPV  sensor  imagery.  Alternatively,  various 
techniques  of  automatic  pattern  recognition  could  be  employed,  either  as  an 
adjunct  to,  or  instead  of,  the  human  operator.  Further,  the  possibility  of  a 
completely  blind  weapon  delivery  system,  relying  upon  precise  navigation 
and  target  location,  could  be  considered. 

For  most  system  functions,  several  alternative  implementation  methods  are 
available,  For  example,  a  variety  of  navigation  systems,  such  as  LORAN, 
OMEGA,  TER  COM,  CLASS,  etc,  are  potential  candidates  for  RPV  use. 

An  optimum,  integrated  system  design  would  therefore  require  a  compre¬ 
hensive  cost-effectiveness  analysis,  considering  such  factors  as  air  vehicle 
vulnerability  to  enemy  ground-to-air  weapons,  communications  vulnerability 
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Figure  3.1-1.  Analysis  Process,  Command  Control  (C&C)  for  RVP's 


to  jamming,  weapon  delivery  accuracy,  target  acquisition  probability,  etc., 
for  various  alternative  allocations  of  functions,  implementation  methods, 
mission  types,  tactics,  and  flight  profiles. 

The  more  modest  aims  of  the  present  study,  in  considering  the  subject  of 
physical  control,  are  to  suggest  techniques  and  methods  of  implementation 
that  appear  reasonable  or  fruitful  for  further  study.  The  conclusions  reached 
herein  are  based  upon  several  assumptions,  which  are  documented  in  the 
discussions  of  the  various  problem  areas.  The  value  of  the  conclusions, 
of  course,  is  a  function  of  the  validity  of  these  assumptions.  A  number  are 
highly  judgemental  and,  although  they  appear  reasonable,  would  require 
detailed  analysis  or  experimentation  to  fully  validate  them. 

In  the  development  of  this  analysis,  a  baseline  system  is  postulated,  to  pro¬ 
vide  context  for  the  consideration  of  various  problems  and  to  make  quantita¬ 
tive  estimates  of  various  load  factors.  In  this  baseline  system,  various 
functions  are  allocated  to  Drone  Control  Facility,  Relay  Aircraft,  and 
RPV,  and  specific  implementation  methods  are  assumed  (e.g.,  LORAN  is 
postulated  as  the  navigation  system,  with  position-determining  calculations 
remoted  to  the  DCF),  It  should  be  remembered,  however,  that  this  base¬ 
line  system  is  tentative,  and  was  used  primarily  as  an  analytical  tool. 

Subsection  3,2  identifies  the  functional  capabilities  that  must  be  provided 
to  maintain  control  of  the  vehicle  from  launch  to  recovery.  Assumptions 
concerning  the  principal  RPV  capabilities  that  significantly  affect  the  exer¬ 
cise  of  physical  control  ares 

a.  It  is  assumed  that  there  is  an  automatic  flight  control  system 
(AFCS)  in  the  RPV,  The  AFCS  will,  at  a  minimum,  provide 
the  capability  to  maintain  a  flight  attitude  (direction  of  flight 
plus  level  flight  or  rate  of  climb  or  descend)  established  for 
the  vehicle,  Additionally,  the  AFCS  will  activate  the  control 
surfaces  necessary  to  execute  maneuvers,  a  turn  angle,  or  a 
rate  of  climb  or  descent  directed  by  an  input  command.  Addi¬ 
tionally,  it  is  assumed  that  the  AFCS  will  be  coupled  with  the 
terrain  following  radar  to  maintain  a  preset  terrain  clearance. 

b.  There  will  be  a  coupling  between  the  steerable  electro-optical 
(£0)  system  and  the  AFCS  which  will  enable  the  AFCS  to 
initiate  turns  and  climb  or  descend  maneuvers  which  will 
maneuver  the  vehicle  into  a  line  of  flight  at  which  the  zero 
setting  on  the  electro-optical  system  (the  setting  that  aligns 
the  electro -optical  sensor  with  the  weapon  boresight)  is  on  the 
electro-optical  aiming  point. 

G,  Positioning  and  maintaining  the  electro- optical  sensor  on  an 
aiming  point  will  be  initiated  by  an  operator  at  the  weapon 
control  console.  Signals  controlling  the  £0  sensor  will  be 
automatically  generated  and  transmitted  to  the  RPV  over  a 
command  link.  Coupling  between  the- electro-optical  sensor 
and  the  AFCS  wilt  be  enabled  and/or  dieabled  by  the  operator. 
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Given  these  capabilities  on  the  RPV,  the  functions  that  must  be  provided  to 
exercise  physical  control  can  be  listed  (Table  HI.  2-1).  Column  1  identifies 
the  functional  area.  Column  2  the  associated  operational  requirement,  and 
Column  3  the  application  of  the  capability.  The  fust  two  functions  listed, 
Navigation  and  Communications,  are  required  by  the  operation  concept.  The 
performance  requirements  for  navigation  are  constrained  by  cost  factors, 
and  other  complex  trade-offs,  such  as  navigation  accuracy  versus  require¬ 
ments  for  target  acquisition.  Subsection  3. 2.  3  reviews  the  results  of  pre¬ 
vious  studies  of  navigation  systems  for  RPV  and,  based  on  selected  imple¬ 
mentation  methods,  develops  requirements  on  the  DCF  related  to  obtaining 
and  maintaining  RPV  position  data. 


Table  III.  2-1.  Physical  Co&.rol  Functions 

Function  Requirement  Application 

Navigation  Establish  position  of  RPV  Necessary  so  cor- 

in  near  real  time  rective  controls 

can  be  applied 

Communications  Provide  cor^nunications  Position  and  status 

between  RPV  and  the  data  reporting, 

RPV  control  site  transmit  control 

data 

Status  A  Position  Monitor  RPV  Flight,  Establish  require - 

detect  exceptions  ment  for  correc¬ 

tive  controls 

Flight  Control,  Maintain  preplanned  Necessary,  to 

Enroute,  Return  to  base  Flight  profile  achieve  mission 

objectives 

Flight  Control,  O srride  preplanned  Necessary  to  deal 

Enroute,  Return  to  base  Flight  profile  with  exceptions 

Control,  over -tbs-  Precise  positioning  of  Necessary  to  ac- 

target  Strike  mission  RPV  for  bomb  release  quire  target  and 

achieve  CEP  ac¬ 
curacy  required 
and  provide  real 
time  BDA, 

Control  On  Station  Activate  and  control  EW  Necessary  to  a- 

Electronic  Warfars  (EW)  Sensor  Package,  dispense  chieve  misalon 

EW  packages  objective 

Control  over -the -target  Activate  aad  control  Necessary  to  a- 

Recce  Mission  ueneors,  control  trana-  chieve  mieeion 

miss. on  of  Recce  data  objective 


The  performance  requirements  for  the  communications  system  are  derived 
specifically  from  operational  requirements,  such  as  secure  jam-resistant 
communications  with  multiple  RPV's  and  visual  acquisition  of  a  target  to 
achieve  required  CEP's.  Communications  Requirements  are  also  derived 
from  the  method  of  exercising  flight  control  and  the  amount  of  status  data  res 
quired  for  various  mission  phases.  Subsection  3. 2. 2,  Communications  Sub¬ 
system  Baseline,  describes  the  communications  system  assumed  for  the 
RPV,  based  on  the  requirements  and  concepts  developed  under  the  multi¬ 
mission  studies  and  compatible  with  the  requirements  to  exercise  physical 
control  defined  in  the  present  study.  The  concepts  for  physical  control  and 
the  associated  communications,  data  processing  and  operator  requirements 
are  developed  in  Subsections  3.2.4  through  3.2.6. 

3.2.2  Communications  Subsystem  Baseline 

This  subsection  describes  the  communications  system  which  has  been 
assumed  for  study  purposes.  The  goal  was  to  select  a  reasonable  baseline 
system  so  as  to  develop  physical  control  procedures  which  are  compatible 
with  the  communications  system,  and  to  establish  the  impact  of  the  commun¬ 
ications  subsystem  on  the  DCF  ADP  system.  The  approach  selected  is 
judged  cost  effective,  considering  operational  requirements  and  communica¬ 
tions  technology.  Data  developed  under  the  Air  Force  funded  studies  are 
specifically  included. 

Two  basic  communications  links  are  postulated.  One  is  a  sensor  link  trans¬ 
mitting  data  for  target  acquisition  and  lock  on.  The  other  is  a  command 
response  link  used  to  receive  data  from  the  RPV  and  to  transmit  control  data. 
The  sensor  link  for  the  Strike  RPV  is  a  special  requirement.  The  assump¬ 
tion  is  that  it  is  provided,  The  principal  alternatives  that  exist  relate  to  bit 
rates  required  to  provide  the  necessary  resolution,  but  these  do  not  signifi¬ 
cantly  Impact  the  physical  control  function.  The  command  response  link 
introduces  mors  operational  factors  impacting  system  design.  Excluding 
the  special  requirements  of  over-the-target  operations  for  strike  missions, 
the  command  response  link  it  characterised  by  the  requirement  to  period¬ 
ically  or  aperiodicaUy  contact  many  RPV's  (up  to  20  per  RPV  unit)  distrib¬ 
uted  over  enemy  territory,  and  possibly  hundreds  of  miles  apart.  Opera¬ 
tional  requirements  considered,  normal  contact  intervals  with  each  RPV 
should  not  exceed  something  like  one  minute,  while  contact  intervals  around 
10  seconds  art  satisfactory  minimum  for  design  purposes.  Contact  intervals 
of  less  than  one  second  do  not  appear  operationally  useful.  On  each  contact 
the  information  exchange  required  is  low;  frequently  no  information  need  be 
exchanged  except  that  needed  to  maintain  navigation  position. 

Over -the -tar get  considerations  are  quite  different.  The  sensor  link  must 
be  maintained.  Additionally,  the  command  response  link  must  be  available 
to  a  given  RPV  on  demand  within  fractions  of  seconds.  For  certain  appli¬ 
cations  no  unpredictable  delay  is  tolerable.  Compared  to  the  enroute  {dieses, 
information  exchange  on  the  command  response  link  is  relatively  high. 
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Bated  on  such  considerations,  the  following  concept  is  assumed.  Two 
command  response  links  will  be  available.  One  is  designed  for  enroute 
control,  the  other  for  over -the -target  control.  The  concept  is  such  that 
the  one  can  provide  backup  for  the  other,  although  there  would  be  some 
degradation  in  the  total  system  capability. 

The  enroute  command  response  link  is  a  steerable  beam  with  a  beam  width 
of  less  than  5°.  RPV's  are  contacted  on  a  round  robin  basis.  The  contact 
interval  per  RFV  mission  is  in  the  order  of  ten  seconds.  This  implemen¬ 
tation  requires  a  determination  of  pointing  angles  for  each  contact.  The 
concept  assumes  that  this  is  accomplished  as  follows: 

Normal  method:  With  10  second  contacts,  an  RPV  approximately 
centered  on  a  communication  beam  footprint  will  not  have  moved 
out  of  the  footprint  before  the  next  contact.  The  relay  aircraft  on 
each  contact  nulls  on  the  signal  which  provides  the  best  pointing 
angle,  aaimuth,  and  elevation  for  the  relay  aircraft.  The  RPV 
pointing  angle  is  the  reciprocal  of  this,  which  is  transmitted  to  the 
RPV  as  a  command.  This  function  is  presumed  to  be  performed 
on  the  relay  aircraft. 

Initial  acquisition,  and  reacquisition  if  contact  is  lost:  For  the 
initial  contact  and  during  handover  between  multiple  relays,  the  point¬ 
ing  angle  is  calculated  using  the  position  of  the  relay  aircraft  and  the 
expected  position  of  the  RPV  when  the  first  contact  is  to  be  made.  To 
reacquire  an  RPV  that  has  been  "lost,  "  or  one  that  has  been  predict¬ 
ed  to  be  out  of  contact  because  of  terrain  masking  (see  Subsection 
3.  3, 3)  the  pointing  angle  is  calculated  using  the  position  of  the  relay 
aircraft  and  the  predicted  position  of  the  RPV.  This  function  is  allo¬ 
cated  to  the  DCF,  Assuming  an  initial  calculation  of  pointing  angle 
and  a  calculation  to  reacquire  once  each  five  minutes,  12  calculations 
per  mission  are  required  (average  mission  time:  60  minutes). 

Over  the  target,  the  second  command  response  link  is  established  on  the 
broad  band  link  used  for  the  sensor  data.  Although  the  primary  sensor  link 
is  one-way  (from  RPV  to  relay)  the  antennas  can  be  used  to  establish  a 
command  link  in  the  opposite  direction  (see  Subsection  2.  7.4).  A  pointing 
angle  is  calculated  for  each  pop-up  point,  or  for  some  point  prior  to  pop-up 
if  desired.  Once  established,  the  relay  aircraft  tracks  the  RPV  continu¬ 
ously  and  transmits  commands  as  necessary.  The  RPV  response  ie  multi¬ 
plexed  on  the  video  link  providing  near  instantaneous  status  data,  (see  Sub¬ 
section  3, 2. 6.4).  Commands  are  transmitted  from  the  relay  aircraft  sensor 
receiving  antenna,  providing  a  command  link  on  demand.  Since  this  antenna 
may  be  pointed  in  any  direction,  it  can  be  pointed  at  any  RPV  enroute  and  be 
ueed  to  back  up  enroute  command  response  communications.  The  sensor 
link  under  these  circumstances  can  be  used  for  visual  reference  or  navigation 
fixes.  Program  requirements  to  calculate  the  pointing  angles  are  identical 
to  the  enroute  phase.  Assuming  two  targets  per  etrike  mission  (two  actual 
Strikes,  or  an  over -the -target  abort  and  divert  to  secondary  target)  and  ono 
visual  fix  enroute  there  ere  on  the  average  three  calculations  per  strike 
mission. 
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3w  2.  3  Navigation  Subsystem  Baseline 

This  subsection  describes  the  navigation  subsystem  which  has  been  assumed. 

The  purpose  is  to  select  reasonable  baseline  alternatives  so  physical  control 
procedures  can  be  developed  which  are  compatible  with  the  navigation  system 
capability  and  so  the  impact  on  the  DCF  ADP  system  can  be  established. 

Data  developed  under  th,e  Air  Force  funded  studies  are  specifically  considered. 

It  was  assumed  that  the  navigational  accuracy  provided  by  the  system  ranges 
from  300  feet  to  150.0  feet  at  maximum  range  (over-the-target  pop-up  point). 
Trade-offs  within  these  limits  significantly  affect  the  electro -optical  sensor 
design  requirements  but  do  not  significantly  affect  the  physical  control  func¬ 
tion,  The  primary  candidate  systems,  as  developed  under  the  Air  Force 
funded  studies,  are  LORAN  and  the  Omega  System. 

Considering  LORAN,  it  has  been  suggested  (Reference  USAF  Rand  Project 
Report)  that  the  use  of  a  fully  self-contained  system  on  the  RPV  would  be 
expensive  and  unnecessary.  For  RPV  application,  an  implementation  in 
which  the  RPV  retransmits  the  LORAN  signal  received  by  the  RPV  over  the 
response  link  with  the  actual  navigation  computation  being  made  in  the  DCF 
(or  possibly  the  relay  aircraft)  would  be  more  cost  effective.  Applying  this 
concept  and  drawing  on  data  available  for  other  applications,  it  has  been 
estimated  that  the  data  transmitted  by  the  RPV  needed  to  make  the  navigation 
fix  calculation  is  40  bits  (Time  differences  of  LORAN  Signals  Master  Slave  #1 
and  Master  Slave  #2).  The  estimated  data  base  required  in  the  DCF  to  calcu¬ 
late  navigation  fixes  is  280  data  words  (36  bits)  each.  An  additional  15  words 
data  base  and  100  instructions  are  estimated  for  tracking,  position  smoothing, 
and  velocity  computations.  Program  requirements  are  estimated  to  be  675 
instructions. 

TJke  LORAN  algorithm  op  which  this  computer  requirement  is  based  consists 
of;  1)  a  control  module,  2)  a  range  and  bearing  computation  module,  3)  a  time 
difference  computation  module,  and  4)  a  LORAN  position  error  estimator. 

This  algorithm  has  been 'implemented  and  dees  perform  satisfactorily. 

The  position  smoothing  and  velocity  computation  algorithm  used  here  for 
estimation  purposes  is  a  DSD-developed  modified  Kalman  filter.  It  has  been 
incorporated  in  several  operational  systems  (CEDPS,  TSQ-73),  where  it 
operates  in  a  track-while-scaa  mode,  In  the  RPV  context,  performance  can 
be  improved  by  making  explicit  use  of  the  priori  knowledge  of  the  time  of 
occurrence  and  the  extent  of  vehicle  maneuvers. 

Assuming  a  10  second  update  rate  per  RPV  (see  Subsection  3.2.2),  the  dead 
reckoning  navigation  errors  that  can  develop  (horizontal  wind  is  the  principal 
variable)  and  the  inherent  accuracy  of  LORAN,  navigation  updates  more 
frequently  than  10  seconds  are  not  required.  Lets  frequent  update  rates 
ere  tolerable*  though  conditions  can  occur  in  which  update  rates  that  signif¬ 
icantly  taceed  10  seconds  are  undesirable.  Considering  that  the  processing 
require^  SO  provide  a  navigation  fix  is  approximately  775  instructions  with 
10  |S.SS<:^4 rate  and  20  RPV'*  to  be  updated,  the  processing  rate  is 
1550  instructions /second  which  it  not  excessive.  It  is  concluded  that  10 
Mpcoxki  navigation  updates  per  RPV  allows  success  in  attaining  mission  objectives. 
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Considerations  of  the  Omega  System  are  similar  to  LORAN.  Specifically, 
use  of  the  Omega  System  instead  of  LORAN  introduces  comparable  data 
reporting  and  processing  requirements.  This  alternative  does  not  signifi¬ 
cantly  impact  the  physical  control  function  nor  the  DCF  data  processing 
requirements. 

A  third  viable  candidate,  described  in  Subsection  2.7.9,  uses  the  Commun¬ 
ications  Command  response  links  to  establish  navigation  position.  Given 
two  relay  aircraft,  it  is  relatively  simple  to  provide  a  time  measuring 
scheme  that  can  be  used  to  measure  path  lengths  to  accuracies  on  the  order 
of  100  feet.  The  additional  system  requirement  is  to  provide  the  capability 
to  automatically  solve  the  geometry  problem  to  yield  RPV  position.  Quan¬ 
titative  estimates  on  the  ADP  support  requirements  have  not  been  developed 
but  they  are  modest. 

The  solution  is  attractive  since,  with  this  implementation,  the  RPV  System 
is  self-sufficient.  It  does  not  require  a  separately  deployed  navigation 
system  in  employment  areas  where  LORAN  or  Omega  are  not  in  place.  The 
disadvantage  is  that  two  relay  aircraft  are  required  to  provide  the  riavigation 
fix.  There  is,  however,  some  possibility  that  a  satisfactory  method  can  be 
provided  to  measure  distance  from  the  DCF  to  the  RPV  using  an  HF  Link. 

3.2.4  Status  and  Position  Reporting 

There  are  basically  thro*  positions  that  might  be  considered  in  status  and 
position  reporting.  One  position  is  to  report  data  providing  continuous  or 
frequent  assurance  that  the  system  is  functioning  normally;  i.e.  that  there 
are  no  malfunctions.  To  achieve  this  objective,  the  status  of  all  critical 
system  elements  must  be  reported,  and  therefore,  reporting  requirements 
are  maximised.  A  second  position  is  to  report  malfunctions  only;  i.e.,  to 
report  by  exception.  Such  an  implementation  presupposes  a  capability  to 
identify  ail  failures  or  deviations  from  normal  (or  standard)  that  can  occur 
and  predetermine  whether  the  failure  or  deviation  affects  mission  success. 
Status  reporting  requirements,  however,  are  minimum.  The  problem  is  to 
predetermine  what  failures  and/or  deviations  are  significant.  In  practice, 
the  third  position  is  most  common.  Actual  reporting  requirements  are  a 
compromise  between  the  two  extremes.  Failures  or  deviations  are  reported 
that  may  or  may  not  significantly  affect  success.  The  decision  to  take  cor¬ 
rective  action  or  plan  for  contingencies,  should  subsequent  reports  show  a 
need  for  corrective  action,  is  allocated  to  a  human  operator.  In  addition, 
certain  status  data  that  provide  assurance  that  operations  are  proceeding 
normally  are  also  reported. 

This  subsection  develops  data  on  the  reporting  of  RPV  status  and  position 
data.  The  basic  position  results  from  the  following  arguments 
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a.  All  malfunctions  affecting  mission  success  should,  ideally,  be 
reported. 

b.  However,  the  cost  to  predict  and  detect  all  malfunctions  that 
can  affect  mission  success  is  high. 

c.  Operator  assurance  that  the  mission  is  being  executed  success¬ 
fully  is  also  important. 

d.  The  cost  to  generate,  communicate,  and  process  reports  is  a 
significant  factor  in  selection  of  data  items  to  be  reported. 

e.  The  Status  data  that  is  reported  must  be  the  basis  for  making 
physical  control  decisions  and  generating  control  commands. 

Since  operational  requirements  and  cost  factors  depend  on  the  mission  phase, 
reporting  requirements  are  addressed  by  mission  phase.  Table  HI.  i-Z 
Status  and  Position  Reporting  Requirements,  summarizes  the  requirements 
that  have  been  developed.  The  considerations  used  to  develop  these  d&ta 
are: 

PRE 1AUN CH t  A  vehicle  has  been  selected  for  a  mission,  configured  as  re¬ 
quired  by  the  mission  plan,  checked  and  determined  to  be  suitable  for  the 
mission,  and  positioned  on  the  RPV  launcher.  At  this  point  in  the  process, 
a  final  prelaunch  check  is  made  to  provide  assurance  that  all  preparations 
for  launch  have  been  accomplished  and  that  selected  system  elements  pass 
prelaunch  tests.  A  ground  communications  link  between  the  launch  facility 
and  the  DCF  is  assumed  so  the  cost  of  transmitting  status  data  is,  within 
reasonable  limits,  independent  of  the  amount  of  data  transmitted.  The 
limiting  factors  are  what  can  meaningfully  be  tested  at  the  launch  site  and 
what  can  practically  be  assimilated  at  the  DCF.  It  is  assumed  that  a 
check  list  of  about  30  items  it  reported  to  the  DCF  and  displayed  on  a 
tabular  display.  Assuming  25  characters  per  item,  one  byte  per  charac¬ 
ter,  this  is  a  750  byte  message,  which  can  be  formatted  for  display  on  an 
60  character  per  line,  15  line  tabular  display.  It  imposes  no  significant 
ADP  or  display  system  requirements.  Assuming  that  usually  the  system 
checks  OK,  typical  operator  time  to  assess  the  report  is  judged  to  be  30 
seconds  (time  to  reed  and  determine  that  all  items  are  OK  is  approximately 
10  ascends), 

LAUNCH:  The  prelaunch  checkout  has  been  passed  and  engine  startup  *5 
initiated.'  Following  engine  startup,  another  sequence  of  checks  and  statin* 
reporting  is  initiated.  Types  of  data  reported  include  engine  RPM,  fuel 
flow,  engine  pressure  ratio,  oil  pressure,  hydraulic  pressure,  etc.  Addi¬ 
tionally,  control  responses  are  checked  by  initiating  preprogrammed  somrol 
instructions  sad  by  receiving  status  data  on  the  response  to  such  cw'tri 
instructions.  As  with  prelaunch,  communications  are  over  die  grov^A^nk 
and  are  not  a  significant  performance  parameter.  (Message  lengM  is  Assum¬ 
ed  to  be  1 00  bytes. )  A  launch  checkout  program  is  required  as  is  a  status 
display  for  the  operator.  Operator  time  is  judged  to  be  30  seconds.  The 
final  operator  action  ia  to  initiate  launch. 
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ENROUTB  AND  RETURN  TO  BASE:  Requirements  to  report  status  of  the 
R£v  enroute  are  primarily  based  on  the  concept  of  reporting  by  exception, 
with  complete  status  reported  only  on  demand.  However,  position  data, 
communications  status,  and  overall  RPV  status  are  routinely  reported. 

These  latter  requirements  are  derived  in  part  from  the  physical  control 
procedures  that  are  described  in  subsection  3.  2.  5  and  in  part  from  the  need 
to  provide  assurance  to  the  human  controller  that  the  mission  is  proceeding 
as  planned.  Applying  these  concepts,  the  following  status  reports  are 
assumed: 

a.  Acquisition  of  the  RPV  by  the  communications  system  verified. 
This  occurs  once  per  acquisition,  and  two  bytes  is  assumed  as 
the  message  size, 

b.  Position  Data  is  sent  each  10  seconds  with  40  bits  per  trans¬ 
mission  (see  subsection  3.2,3). 

c.  Communications  Contact  Status,  is  also  transmitted  each  10 
seconds,  (achieved  or  not  achieved)  and  is  estimated  at  two 
bits. 

d.  RPV  Condition  Status,  is  reported  each  10  seconds,  (normal 
or  not  normal)  and  Is  two  bits. 

e.  Amplifying  data  on  malfunctioning  subsystem  status  is  estimated 
at  240  bits  per  report.  Ten  reports  per  mission  are  assumed 
although  these  estimates  may  be  on  the  high  side. 

f.  Radar  Homing  and  Warning  (RKAW):  Assuming  the  RPV  is 
instrumented  to  detectacquisition  by  radar,  three  states  are 
reported*  OFF,  ON  (not  activated)  and  ON  (activated).  Two 
bits  can  be  used  to  report  any  state.  The  simple  solution  is 
to  report  complete  status  on  each  contact. 

QVIBR »T BIS -TARC^BT_..ON, STATION i  The  requirement  to  report  status  per 
«  ouring  't^e  over"  the ~&rg«t"pHes«  of  strike  missions  is  basically  die  same 
at  snroutc.  Although  additional  status  data  are  inherent  in  the  video  picture 
this  it  not  interpreted  as  being  status  in  the  context  of  staius  reporting. 
Special  status  reports  over-the-target  include  such  information  as  EO  sensor 
flight  control  coupling  enabled,  lock  on  achieved,  and  bombs  released.  On 
tide  ordsr  of  3Q0  bits  per  strike  are  assumed,  Special  on  station  status 
reporting  for  EW  and  Recce  are  similar.  In  response  to  commands  to 
point  and  activate  sensors  ths  fact  that  the  command  Has  executed  is  re¬ 
ported.  As  with  Strike  missions,  300  bits  are  assumed. 
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RECOVERY*  The  operational  assumption  is  that  the  RPV  is  recovered  by 
parachute.  Recovery  is  controlled  by  a  ground  crew,  Within  the  DCF, 
there  is  a  requirement  to  receive  data  verifying  that  the  recovery  crew  is 
m  place  and  ready  to  assume  recovery  control.  Certain  status  data  are 
required  from  the  RFV;  e.  g. ,  that  tne  engine  has  been  abut  down,  fuel  is 

Oata  rates  are  low,  possibly  40  bits  per  message, 
with  10  messages  operator  time  is  likewise  low}  on  the  order  of  30  seconds. 


3.2.5  Flight  Control.  En route.  Return  to  Base 
3. 2.  5. 1  Introduction 

This  section  addresses  the  requirement  to  maintain  a  preplanned  flight-  pro¬ 
file  and  schedule.  A  fundamental  assumption  is  that  a  preplanned  mission 
profile  and  schedule  have  been  generated  which  are  to  be  realized  in  the  exe¬ 
cution  of  the  mission.  Alternate  and  secondary  targets  are  preplanned  and 
the  criteria  under  which  a  preplanned  alternative  is  selected  are  established. 

Generation  of  such  a  preplanned  flight  profile  is  addressed  in  subsection  3.3, 
Force  Control  Functions.  This  section  begins  with  the  requirement  for  the 
physical  control  function  to  fly  the  mission  as  planned  or,  if  this  is  not  pos¬ 
sible,  to  make  adjustments  to  the  mission  profile  and/or  schedule  as  neces¬ 
sary,  Any  conditions  that  may  cause  the  mission  not  to  be  executed  as 
planned  are  reported  to  the  Force  Control  function. 

The  physical  control  function  then  provides  control  instructions  to  the  RPV 
such  that  the  vehicle  will  maintain  the  preplanned  flight  profile  and  schedule. 
To  accomplish  this,  it  is  necessary  to  obtain  position  data  on  the  RPV,  com¬ 
pare  the  actual  position  with  the  planned  position,  and  establish  what  control 
is  to  be  executed  to  maintain  the  planned  profile.  Communication  with  the 
RPV  is  essential. 

Considering  these  data  as  inputs,  and  the  basic  feature  of  the  RPV,  (that  the 
vehicle  can  be  controlled  in-flight)  there  are  two  basic  approaches  to  flight 
control. 

One  approach  depends  upon  the  DCF  to  initiate  all  control  necessary  to 
change  the  flight  parameters.  That  is,  the  AFCS  on  the  vehicle  maintains 
the  flight  attitude  and  the  speed  or  power  mode  initiated  by  the  controller. 

The  RPV  controller  is  required  to  initiate  ail  enroute  maneuvers  to  position 
the  vehicle  along  a  desired  and  preplanned  profile.  Frequent  contact  for 
control  Is  necessary  unless  the  preplanned  profile  is  limited  to  a  few  in¬ 
flight  maneuvers,  If  the  time  of  maneuver  is  critical,  control  directions 
must  be  transmitted  at  exactly  the  position  or  clock  time  that  the  turn,  for 
example,  is  to  be  initiated.  U  communications  are  lost,  control  is  lost. 

The  second  approach  is  to  preprogram  the  in-flight  maneuvers  and  to  store  the 
preprogram  flight  profile  aboard  the  RPV.  The  RPV,  while  enroute,  first  inter¬ 
prets  preceded  instructions  and  then  maneuvers  to  maintain  a  planned  flight 
profile.  Precoding  alone,  however,  is  unacceptable  oecause  unpredictable  var¬ 
iables,  such  as  winds,  density  altitude  values,  engine  and  airframe  efficien¬ 
cies  are  such  that  position  errors  build  up  to  unacceptable  levels.  This 
deficiency  can  be  overcome  if  a  navigation  system  that  provides  data  on  the 
location  of  the  RPV  is  available.  Such  a  system  is  inherent  in  the  RPV  Sys¬ 
tem  Concept  and  is  assumed  t  >  be  existent  for  this  analysis.  Position  data, 
or  data  necessary  to  establish  position,  are  transmitted  to  the  physical  con¬ 
trol  element.  The  actual  position  of  the  RPV  relative  to  the  planned  position 
can  be  established.  If  the  difference  exceeds  a  threshold  value,  the  physical 
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control  element  intervenes  and  issues  corrective  maneuvers  causing  the 
RPV  to  re -attain  the  planned  schedule.  (These  functions  could,  of  course, 
be  allocated  to  the  RPV,  but  the  additional  complexity  of  the  RPV  on-board 
processor  does  not  appear  to  be  justified. ) 

This  composite  approach  is  more  economical  in  terms  of  operator  time.  If 
communi cation  with  the  vehicle  cannot  be  maintained,  the  vehicle  continues 
to  maneuver  to  maintain  the  planned  flight  profile.  These  are  very  signifi¬ 
cant  advantages. 

For  either  approach,  accurate  navigation  is  a  requirement.  Further,  pro¬ 
viding  communications  on  demand  to  all  RPVs  at  all  times  is  costly,  while 
the  cost  of  providing  the  capability  to  pre-program  the  RPV  is  not  high. 
Considering  these  cost  factors  in  relationship  to  requirements,  the  com¬ 
posite  approach  is  selected  as  the  preferred  approach. 

3.  2.  5.  2  Physical  Control  Implementation  Concepts 

Physical  control  of  the  RPV  is  based  on  the  premise  that  there  is  a  pre¬ 
programmed  flight  profile  on  board  the  RPV  coupled  with  the  AFCS,  Without 
any  commands  from  the  physical  control  element  the  RPV  maneuvers  to 
maintain  the  flight  profile  and  schedule  as  programmed.  Details  of  how 
such  a  precoded  flight  profile  is  generated  and  the  data  needed  to  store  a 
profile  is  contained  in  sub-section  3.3.  2,  RPV  Flight  Profile  Program  and 
Insertion.  Additionally,  the  control  concept  includes  the  requirement  to 
be  able  to  change  the  preplanned  flight  profile  enroute.  The  consequence  is 
that  it  is  not  necessary,  under  this  concept,  to  preload  the  total  flight 
profile.  Segments  can  be  inserted  enroute  in  periods  of  communications 
contact.  The  only  constraint  is  that  a  segment  must  be  inserted  before  it  is 
to  be  executed;  otherwise  the  mission  will  abort. 

With  such  a  concept,  if  all  systems  function  perfectly  and  if  the  planned 
ground  speed  and  path  are  realised  within  threshold  tolerances,  there  would 
be  no  requirement  for  enroute  control  external  to  the  RPV.  Such  conditions 
cannot  be  expected.  Atmospheric  winds,  temperatures,  and  density  alti¬ 
tudes  will  not  be  exactly  as  forecast;  engine  thrust  and  vehicle  drag  values 
will  not  be  exactly  as  estimated;  and,  a  terrain  following  flight  profile  cannot 
be  exactly  predicted.  The  vehicle  will  drift  off  course  and  will  fail  to  main¬ 
tain  the  pre-programmed  airspeed  and  groundspeed,  even  with  all  system 
elements  functioning  normally.  To  compensate  for  this,  control  instructions 
to  adjust  power  setting  (or  fuil  flow)  and  direction  of  flight  will  be  required. 

With  these  factors  in  mind,  the  following  control  procedures  are  proposed. 
The  RPV  position  is  established  using  status  inputs  from  the  RPV  (see  sub 
ssctlon  3. 2.  3),  The  actual  position  is  compared  to  the  planned  position.  If 
the  deviation  exceeds  a  threshold  value  (position  deviations  in  hundreds  of 
feet,  schedule  and  time  deviations  in  seconds),  a  computation  is  made  to 
establish  the  new  heading  required  to  make  good  the  preplanned  flight  path 
and  the  power  increase  or  decrease  needed  to  adjust  airspeed  to  make  good 
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the  schedule  times,  (It  is  assumed  that  the  AFCS  on  the  RFV  will  maintain 
the  preplanned  altitude  within  tolerance. )  The  control  commands  are  gen¬ 
erated  and  transmitted  to  the  RPV  over  the  command  link.  The  exact  time 
of  transmission  is  not  critical.  All  of  these  functions  are  automated  and  can 
be  executed  without  operator  intervention. 

Under  this  concept,  the  operator  intervenes  only  when  deviations  are  detected 
that  cannot  be  corrected  simply  by  altering  heading  and/or  power  setting. 

Such  deviations  may  result  from  system  malfunctions  that  have  not  yet 
affected  the  flight  but  that  may  foreshadow  problems.  Possible  examples 
are;  1)  a  loss  of  communications  because  of  terrain  shielding  or  enemy 
jamming,  or  2)  tailpipe  temperature  exceeding  a  threshold  value  but  not  yet 
affecting  engine  thrust.  Excessive  path  deviations  may  be  reported  resulting 
from  extreme  deviations  in  atmospheric  conditions,  RPV  malfunctioning,  or 
navigation  data  error.  In  addition  to  operator  intervention,  all  deviations 
that  may  affect  mission  success  must  be  reported  to  the  force  control  ele¬ 
ment  of  the  system. 

It  is  not  possible  nor  even  necessary  to  identify  all  possible  causes  or  types 
of  deviations.  Considering,  however,  those  that  are  likely,  it  is  possible  to 
identify  the  control  functions  required  for  physical  control.  Table  111,2-3, 
RPV  Control,  Enroute  Control  Functions,  lists  these  requirements.  The 
list  is  based  in  part  on  familiarity  with  similar  control  systems  and  in  part 
on  the  control  functions  unique  to  RPV  and  the  control  concepts  selected. 
Although  some  critical  functional  capability  may  have  been  omitted,  the  list 
is  generally  believed  to  be  quite  complete.  Functions  identified  with  tn 
asterisk  are  required  specifically  for  over-the-target  control  of  the  RPV 
strike  mission.  They  may  also  provide  capabilities  that  can  in  many  cases 
be  useful  in  enroute  control,  assuming  that  the  use  is  on  a  no  interference 
basis  with  over-the-target  control. 

3. 2. 5. 3  Physical  Control,  Exceptional  Conditions 

Under  the  present  concept,  normal  flight  is  highly  automated  and  corrective 
control  is  only  applied  in  response  to  unpredicted  variables.  However,  it 
must  be  anticipated  that  exceptions  requiring  such  control  will  occur,  The 
RPV  flight  control  system  must  have  the  capability  of  detecting  various  emer¬ 
gency  conditions  and  adopting  preplanned  contingency  instructions  and/or 
other  emergency  control.  Malfunctions  of  RPV  subsystems  necessary  to 
mission  completion,  including  loss  of  communication  with  the  Drone  Control 
Facility,  constitute  these  emergencies. 

As  long  as  communication  is  maintained,  the  RPV  need  not  be  preprogrammed 
to  change  course  in  the  event  of  equipment  malfunction.  However,  the 
specific  type  A  malfunction  must  be  communicated  to  the  DCF.  The  more 
complex  ease  occurs  with  loss  of  communications,  particularly  on  she  DCF 
to  ItPV  command  link. 

With  programmed  flight  profiles,  a  temporary  loss  of  communications  with 
the  ground  can  be  tolerated  for  a  considerable  period  of  time  in  the  enroute 
phases  of  a  mission.  For  illustration,  assume  that  without  course  correc¬ 
tions  from  tits  physical  control  element  system,  the  RPV  heading  diverges 


Table  III.  2-3.  RPV  Control,  Enroute  Control  Functions 


1.  Compute  RPV  position. 

2.  Compare  computed  position  with  planned  position. 

3.  Compute  speed,  heading,  altitude  commands. 

4.  Prepare  data  link  messages. 

5.  Determine  requirement  for  altering  course  (change  legs  to 
affect  arrival  time). 

6.  Monitor  communications  continuity. 

7.  Generate  alert  messages  for  console  operators. 

8.  Display  planned  vs.  actual  course  and  position. 

9.  Display  situation  data,  including  terrain,  FEBA,  hostile  AAA, 
targets  for  selected  portion  of  RPV  flight  profile. 

10.  Display  RPV  status  information:  e.g.,  fuel,  weapons,  pri¬ 
mary  and  alternate  targets,  recovery  base,  TOT,  etc. 

11,  Generate  routine  reports  automatically. 

12/  File  recorded  video,  photo,  IR  data,  on  targets  and  prominent 
land  marks  for  subsequent  retrieval  by  geographic  location. 

13?  Display  filed  geographic  data  in  conjunction  with  live  video,  or 
IR  for  easy  comparison, 

14.  Display  current  RPV  location  and  heading  in  conjunction  with 
map- oriented  target  data  to  facilitate  interpretation  of  file  data 
or  as  substitute  for  it  if  no  previous  data  on  target. 

15*/  Maintain  current  target  intelligence  data,  including  damage  due 
to  other  non-RPV  missions;  (to  the  extent  that  this  would  be 
useful  in  recognising  target  and/or  landmarks  enroute  to  it). 

16.  Monitor  RPV  status  of  on-board  systems,  generating  alternative 
commands  (e.g. ,  abort  mission  and  RTB)  as  required.  May 
include  computing  new  heading  instructions. 

17.  Display  enroute  threats  in  conjunction  with  RPV  current  path. 

18.  Display  special  ingress/egress  lanes  for  friendly  territory  and 
for  launch,  recovery  operations,  in  conjunction  with  launch/ 
recovery  bases. 

19/  Activate /deactivate  video/IR  for  check  points . 

20.  Activate/deactivate  EW  and  RECCE  sensors,  provide  pointing 
commands. 

21/  Record  video/IR  and  select  portions  for  file. 

22.  Maintain  log  of  significant  events  by  location  (e.g. ,  malfunc¬ 
tions,  loss  of  RPV). 

■^Specific  over »the -target  control  functions. 
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from  the  planned  heading  by  1  degree.  At  600  knots,  the  RPV  would  be  off 
course  by  456  feet  after  60  seconds,  or  4560  feet  in  ten  minutes.  For 
enroute  mission  phases,  a  discrepancy  of  4560  feet  would  not  normally  re¬ 
quire  aborting  the  mission.  If  communications  were  regained  at  that  point, 
the  RPV's  actual  position  could  be  computed,  new  flight, profile  instructions 
determined,  and  the  mission  could  regain  its  preplanned  flight  profile  and 
schedule  and  complete  the  mission  exactly  as  planned. 

For  emergencies  in  which  onboard  equipment  fails,  but  the  RPV-to-DCF 
link  remains  operative,  the  onboard  processor  can  be  preprogrammed  to 
report  the  malfunction  in  a  standard  format  digital  message.  (This  was 
assumed  to  be  the  case  in  the  discussion  of  status  message. )  The  DCF  pro¬ 
cessor  can  alert  the  operator  upon  receipt  of  the  message  and  display  the 
nature  of  the  emergency  in  alphanumeric  form  in  conjunction  with  theRPV 
identification. 

For  certain  kinds  of  emergencies,  the  timing  can  be  so  critical  that  it  is 
necessary  to  preprogram  the  RPV  to  take  contingency  actions  automatically, 
without  waiting  for  control  messages  from  the  ground  center.  For  example, 
if  the  terrain -following  subsystem  were  to  malfunction  while  the  RPV  was 
flying  at  600  knots  200  feet  above  the  surface  of  the  ground,  an  automatic 
climb  should  be  initiated  without  waiting  for  a  decision  by  the  DCF.  However, 
it  is  not  always  desirable  to  have  a  fixed  action  automatically  initiated  for 
a  particular  type  of  emergency. 

One  approach  to  contingency  situations,  which  provides  a  great  deal  of  flex¬ 
ibility,  is  as  follows.  For  each  basic  type  of  contingency  that  can  be  sensed 
by  the  RPV,  a  planned  response  is  preprogrammed  for  each  leg  of  the  flight. 
‘Xlien,  if  an  emergency  occurs,  the  RPV  processor  takes  the  action  pro¬ 
grammed  in  terms  of  the  current  flight  leg.  To  clarify  the  idea,  consider 
the  problem  of  aborting  a  mis;  ion  before  the  weapons  have  been  expended. 

It  is  desirable  to  jettison  stores  before  initiating  recovery  of  the  RPV.  How¬ 
ever,  the  preferred  course  of  action  varies  depending  upon  whether  the  RPV 
is  over  friendly  (including  sanctuary),  or  hostile  territory.  Over  frivndly 
territory,  the  preferred  contingency  action,  if  feaeible,  is  to  fly  the  RPV 
over  enemy  territory  (or  over  a  body  of  water  or  unpopulated  friendly  ground) 
before  releasing  stores.  Over  hostile  territory,  when  the  emergency  occurs, 
it  may  be  feasible  to  drop  the  stores  over  known  targets  on  the  route  back  to 
the  recovery  area. 

This  same  principle  of  preprogramming  contingency  actions  for  each  leg  of 
the  flight  can  to  applied  to  the  lose  of  communication*  from  the  ground.  For 
each  leg  of  the  flight,  the  RPV  would  be  given  a  specific  set  of  instructions 
to  follow  in  the  event  of  lose  of  communications  from  the  ground;  after  a 
specified  period  of  time.  For  example,  for  a  particular  leg  of  the  flight,  the 
instructions  might  permit  the  RPV  to  continue  on  ite  programmed  mis  cion 
profile  for  10  minutes,  after  which,  if  no  command  meeeage  were  received, 
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the  RPV  would  switch  to  previously-prepared  new  heading,  speed,  and  alti¬ 
tude  data  that  would  return  it  to  the  recovery  area. 

There  are  two  methods  of  implementing  this  approach  to  contingency  opera¬ 
tions.  One  method  is  to  preplan  all  actions  to  be  taken  for  each  leg  of  the 
flight  profile  for  each  kind  of  contingency  and  store  these  in  the  RPV  ADP 
system.  The  other  method  is  to  use  a  "one-ahead"  approach  and  only  store 
in  the  RPV  the  contingency  actions  to  be  taken  during  the  next  flight  leg,  or 
during  the  next  "N"  minutes.  If  the  latter  approach  is  used,  contingency 
actions  could  be  performed  on  line.  The  method  does,  of  course,  imply 
update  of  the  RPV  prior  to  the  start  of  each  leg. 

3. 2. 5. 4  Operator  Requirements,  Operator  Facilities,  and  ADP  Support 
for  Enroute  Control 

The  physical  control  operator's  station  requires  a  tabular  display  console 
capable  of  displaying  status  data  and  schedule  deviations.  Operator  controls 
to  select  modes,  to  retrieve  data,  and  to  generate  commands  are  obvious 
requirements.  A  situation  display  which  shows  planned  flight  path,  actual 
RPV  position,  target  or  on -station  locations,  threat  zones,  and  restricted 
zones,  while  not  absolutely  essential,  would  add  significantly  to  an  operator's 
capability  to  assess  the  situation  and  deal  with  exceptions.  As  a  result,  a 
requirement  for  a  situation  display  is  postulated. 

The  control  procedures,  along  with  the  associated  operator  time,  ADP 
requirements,  and  the  number  of  command  messages  required,  are  the 
basis  for  quantitative  estimates  of  system  performance  requirements.  These 
items  are  most  easily  presented  in  the  form  of  a  scenario  that  traces  the 
enroute  control  activity  from  launch  to  recovery.  Such  a  scenario  is  pre¬ 
sented  below  for  a  single  mission.  System  loads  are  generated  by  multi¬ 
plying  the  single  mission  factors  by  the  number  of  simultaneous  missions 
as  appropriate. 

Launch  acquisition:  Ihe  launch  procedures  and  the  associated  system  capa¬ 
bilities  required  have  been  described  as  a  sequence  of  status  checks  in 
subsection  3. 2.-4,  Launch  acquisition  is  the  activity  required  to  acquire  the 
RPV  inflight  and  establish  inflight  control.  After  launch,  the  RPV,  following 
its  programmed  flight  profile,  has  reached  a  point  in  space  and  has  estab¬ 
lished  a  flight  attitude..  The  communications  to  be  established  have  been 
preplanned.  When  communication  with  the  RPV  is  initiated,  a  response 
message  containing  navigation  data  and  subsystem  status  indicates  acquisition. 
If  this  initial  communication  contact  is  through  the  relay  aircraft,  the  relay 
aircraft  will  have  been  notified  of  launch  or  time  for  first  contact  and  the 
pointing  angle  to  acquire  the  RPV,  If  local  communications  are  used  for  the 
initial  contact  and  close-in  enroute.  control,  these  communications  will  be 
initiated*  Handover  to  the  relay  aircraft  occurs  at  some  point  enroute. 

When  communications  are  established  and  a  response  is  received,  launch 
acquisition  has  been  completed  and  enroute  control  is  established. 


Periodic  update ■:  A* turning  communications  contact  is  achieved,  RPV 
subsystem  status  is  reported  at  the  appropriate  interval.  If  all  parameters 
are  normal,  processing  within  the  DCF  is  as  follows.  The  time  the  report 
is  received,  stored,  and  replaces  the  time  of  the  most  recent  report  received 
from  this  RPV.  The  RPV  position  is  calculated  based  on  the  navigation 
message.  The  expected  position  is  then  established  from  the  preplanned 
mission  profile  stored  in  the  data  base.  Differences  in  magnitude  and 
direction  between  the  positions  is  computed.  If  this  difference  does  not 
exceed  a  threshold  value,  this  fact  is  coupled  with  the  time  of  the  report 
and  stored.  If  the  position  deviation  exceeds  threshold,  checks  are  made 
on  the  validity  of  the  status  data.  When  the  deviation  is  determined  to  be 
valid,  corrective  controls  are  initiated.  If  the  checks  fail,  the  fact  of  re¬ 
ported  deviation  ie  saved  as  an  indication  of  a  potential  trend.  Estimates  of 
the  sise  of  the  data  base  required,  the  sise  of  the  program  to  process  such 
a  report,  and  the  number  of  instructions  executed  is  tabulated  on  Table  III.  2*4. 

Aperiodic  Control  Directives?  The  procedures  described  above  determine 
whether  corrective  control  actions  are  to  be  directed.  The  threshold  values, 
for  course  and  schedule  have  been  preselected  for  the  specific  mission  and 
mission  phase.  (For  example,  schedule  tolerance  may  be  "high”  for  a 
Recce  mission  relative  to  the  schedule  tolerance  for  a  coordinated  strike 
mission  and  supporting  ECM  approaching  the  target).  If  corrective  direc¬ 
tives  are  required,  the  processor  calculates  the  change  in  direction  of 
flight  and/or  fuel  flow  (or  power  setting)  necessary  to  rejoin  the  programmed 
profile  at  the  profile  segment  end  point.  The  application  program  used  to 
develop  the  precoded  flight  segment,  described  in  subsection  3.3.8,  is  used 
to  code  a  new  segment  and  transmit  it  to  the  RPV.  The  update  rate  for 
control  directives  is  obviously  a  function  of  the  magnitude  of  the  threshold 
values  and  the  magnitude  of  the  variables  (e.g.  wind,  thrust,  drag)  that 
affect  the  RPV  course  and  ground  speed.  For  purposes  of  estimating  system 
loads,  it  is  assumed  that  corrective  controls  are  calculated  and  transmitted, 
on  the  average,  each  5  minutes  to  each  RPV.  (This  process  also  assumes 
that  the  RPV  position  error  did  not  exceed  a  second  threshold  value  requiring 
operator  alert.  Further,  the  magnitude  of  the  control  change*  directed  are 
within  pre»establi«hed  tolerance  levels. ) 

Aperiodic. Confidence  Checkei  It  is  unrealistic,  to  postulate  that  an  enroute 
controller  will  hot  desire  to  or  need  to  monitor  status,  even  when  no  devia¬ 
tion*  are  detected,  thus,  ths  enroute  controller  will  periodically  or  aperi- 
odically  check  status*  Reasonabls  implementation  procedures  are  many, 
ranging  from  a  continuously  updatsd  large  screen  group  status  display,  to 
periodic  printouts  on  a  lint  printer.  For  estimating  purposes,  the  following 
is  assumed*  Two  display  formats  art  available;  a  tabular  dieplay  and  a 
situation  display.  Ths  tabular  format  is  sslectabls  by  mission  number  for 
a  single  mission  or  by  mission  type  and/or  mission  phase  for  group*  of 
missions.  The  data  may  be  displayed  on  the  operator  console  or  on  a  printer. 
The  situation  display  is  a  display  of  mission  geomstry,  planned  flight  profile, 
and  target  or  orbit  station.  The  current  position  of  ths  mission  RPV  symbols 
is  displayed.  Other  data,  e.g.  restricted  *  or.ee,  EOB  data,  are  highly  useful. 
As  with  the  tabular  display,  ths  display  content  is  selectable  by  mission 
number  or  type  mission  and/or  mission  phase.  Other  data,  e.g.  restricted 
son**,  may  also  be  selection  criteria.  There  is  no  reasonable  way  to 
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Table  III.  2-4.  Operator  Time,  Mission  Exceptions 


Operator  Action 

Rate /MSN 

Operator 

Time 

per  Action 

Operator 

Time/MSN 

(seconds) 

ABORT  MSN 

10% 

120  sec 

12 

ADJUST  MSN,  SUCCESS 

NOT  AFFECTED 

3/MSN 

30  sec 

90 

ADJUST  MSN,  SUCCESS 

MAY  BE  AFFECTED 

25% 

90  sec 

22.5 

DIVERT  MISSIONS  AS  DIRECTED 
OPER  TIME/MISSION 

10% 

60  sec 

6 

130.5 

establish  how  frequently  such  "confidence  data"  are  required.  One  may 
postulate  that  if  there  are  no  exceptions  requiring  operator  attention,  the 
operator  may  continuously  or  semi- continuously  monitor  status.  To  the 
extent  that  exceptions  requiring  operator  attention  develop,  "confidence 
checking"  will  be  more  infrequent.  Specific  estimates  of  processing  re¬ 
quired  and  operator  time  for  confidence  checking  is  deferred  to  the  next 
paragraph,  Controller  Response  to  Exceptions  Reported. 

Controller  Response  to  Exceptions;  This  is  the  primary  function  of  the 
enroute  controller,  While  it  is  not  possible  to  identify  all  exceptions  that 
can  occur,  the  nature  of  the  procedure  and  the  ADP  support  requirements 
can  be  described  and  generally  quantified. 

Three  system  elements  directly  impact  RPV  control  functions;  the  relay 
aircraft,  the  RPV  vehicle  system,  and  the  launch/ recovery  facility.  It  is 
assumed  that  each  of  these  systems  is  capable  of  detecting  and  reporting  its 
own  failures  and  abnormal  performance  data.  It  is  assumed  that  the  input 
message  to  the  DCF  from  the  RPV  or  the  relay  is  a  formatted  digital  mes¬ 
sage,  ADP  must  process  the  message,  identify  it  as  an  exception  report  to 
be  displayed,  route  it  to  the  proper  control  station,  and  activate  an  alarm. 
The  controller  requests  display  of  the  message  in  tabular  form.  In  terms  of 
the  control  action  that  can  be  taken  by  the  enroute  controller,  there  are  three 
posaibilitieat 


a.  The  mission  must  be  aborted.  Here,  two  subsets  exist.  If  the 
exception  reported' is  that  the  mission  has  aborted  the  controller 
has  no  choice.  If  the  reported  malfunction  convinces  the  con¬ 
troller  that  the  miseion  must  be  aborted,  implementation  of  the 
operator  decision  is  involved.  If  amplifying  data  on  the  mission, 
the  mission  requirements,  and  the  status  of  other  system  ele¬ 
ments  are  required,  the  capability  to  request  data,  process  the 
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request,  end  display  data  must  be  provided.  Coordination  with 
other  controllers  or  a  supervisor  may  be  necessary,  requiring 
inter -coneoi#  transfer  of  data.  Finally,  the  capability  to  gen¬ 
erate,  address,  and  transmit  an  abort  message  is  required. 

b.  Mission  success  and  successful  recovery  is  not  affected.  Two 
possibilities  exist.  6ne  is  that  the  failure  or  deviation  reported 
may  relate  to  a  system  element  not  neceesary  to  the  euccess  of 
the  mission,  Alternately,  the  reported  exception  is  one  which 

is  tolerable  or  can  be  corrected.  Schedule  deviations,  for  exam¬ 
ple,  of  a  magnitude  that  by  Standing  Operating  Procedures  are 
allocated  to  the  controller  to  decide  what  corrective  control  action 
it  to  be  applied  to  enable  the  RPV  to  make  good  its  preplanned 
schedule  and  flight  profile  within  acceptable  limits.  No  specific 
console  requirements  exist  other  than  the  display  of  the  exception 
massage  and  any  other  data  the  controller  might  need  to  insure 
that  message  success  and  recovery  are  not  affected. 

c.  The  probability  of  mission  Success  is  degraded  or  coordinated 
missions  are  affected.  In  this  case,  the  controller  must  assess 
th2  impact  of  the  delation  reported  and  take  authorized  correc¬ 
tive  action  to  minimize  the  effect  of  the  deviation  on  the  success 
of  the  mission  and/or  maximize  the  probability  of  successful 
recovery.  An  exception  report  must  be  generated  and  trans¬ 
mitted  to  the  RPV  force  control  element  and  to  any  other  ele¬ 
ments  affected.  Again  no  special  console  requirements  are 
derived. 

There  is  one  final  situation  that  can  be  considered  under  the  general  heading 
of  dealing  with  exceptions.  This  is  the  situation  where  the  force  control  ele¬ 
ment  directs  a  change  to  a  mission  flight  profile  and/or  schedule.  The  as¬ 
sumption  here  is  that  if  a  deviation  is  planned  by  the  force  control  element, 
the  new  flight  profile  will  be  planned  and  coded  so  it  can  be  transmitted  to  the 
RPV.  The  RPV  is  capable  of  receiving  an  updated  profile  and,  in  response 
to  coded  segments,  fly  the  new  path.  In  this  situation,  the  divert  message 
is  displayed  to  the  controller.  The  controller  requests  and  receives  a  dis¬ 
play  of  the  RPV  mission  being  adjusted,  <ts  previous  flight  profile,  and  the 
new  flight  profile.  He  verifies  that  the  point  at  which  the  new  profile  is 
chained  to  the  old  profile  is  forward  of  the  current  position  of  the  RPV.  (If 
this  condition  does  not  exist,  an  exception  exists  of  one  of  the  types  previously 
described, )  He  then  transmits  the  new  profile  to  the  RPV  and  verifies  that 
the  message  is  received. 

Factors  derived  under  the  SEEK  FLEX  and  TACC  studies  and  the  Mission 
Planner  experience  permits  reasonable  estimates  of  operator  time  required. 
Table  I)UL$-4  tabulates  the  factors.  The  relevant  factors  are  as  follows) 
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Aborts:  An  abort  rate  twice  that  for  manned  aircraft,  as  specified  for 
TACC,  SS001485A,  is  assumed.  Operator  time  may  be  high  since  aborts 
can  be  automatic,  e.g.,  if  communications  is  lost,  and  thus  do  not  require 
operator  action.  However,  2  minutes  per  abort  appears  reasonable  based 
upon  the  criticality  of  the  decision,  the  factors  to  be  considered,  and  the 
tasks  to  be  performed. 

Mission  Adjustments,  Mission  Success  Not  Affected:  The  activity  level, 

(3  per  mission),  as  well  as  the  operator  time,  obviously  depends  upon  de¬ 
gree  of  automatic  adjustment  which  is  permitted  in  the  system,  and  the 
complexity  of  the  adjustment  process.  The  assumption  is  that  major 
automatic  adjustments  are  not  allowed.  However,  criteria  for  making 
"major  adjustments"  are  preplanned  or  pre-established  and  the  processor 
displays  viable  options.  Some  adjustments  may  well  take  several  minutes, 
and  many  adjustments  require  very  short  periods  of  time,  e.g. ,  10  or  20 
seconds.  The  30  second  average  time  is  based  in  part  on  the  SEEK  FLEX 
simulation  of  the  mission  adjustment  process. 

Adjust  Missions,  Mission  Success  May  Be  Affected:  The  rate,  25%,  is 
deliberately  selected  as  high  because  of  the  lack  of  data.  As  with  other 
adjustments,  operator  time  can  vary  from  20  seconds  to  several  minutes. 

The  average  timo,  90  seconds,  is  based  in  part  on  SEEK  FLEX  simulations. 

Mission  Diverts:  A  low  divert  rate  is  assumed.  Since  the  operator  require¬ 
ment  is  principally  to  verify  that  the  divert  directed  is  possible,  operator 
time  is  low. 

The  operator  time  (130.  5  seconds)  is  the  average  time  required  per  mission. 
In  the  maximum  activity  period  (20  simultaneous  missions),  total  operator 
time  required  for  handling  mission  exceptions  for  20  RPV's  on  simultaneous 
missions  is  43,  5  minutes,  or  0.7  man-minutes  per  minute.  A  considera¬ 
tion  that  enters  into  tolerable  operator  loading,  during  peak  activity  periods, 
is  that  many  adjustment  actions  can  be  deferred  seveial  minutes  without 
affecting  the  success  of  operations. 

Data  processing  required  to  support  these  functions  are  more  difficult  to 
assess.  The  type  of  processing  required  is  highly  operating -system  oriented, 
consisting  of  input  and  output  message  processing,  message  checking,  tabu¬ 
lar  displays,  operator  requests  for  data,  and  data  retrieval  with  fixed  for¬ 
mat  tabular  and  situation  displays. 
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3 . 2 .6  Control,  Over -The  Target  Strike 
3  2.6.1  Introduction 

This  subsection  discusses  functional  requirements  for  physical  control  of 
RPV's  during  the  over-the-target  phase  of  air-to-ground  strike  missions. 
This  phase  begins  with  the  arrival  of  the  RPV  within  target  acquisition 
range  of  the  electro-optical  sensor,  proceeds  through  weapon  delivery  and 
damage  assessment  (including  any  additional  strike  or  BDA  runs  on  the 
same  target  that  are  required)  and  terminates  with  final  escape  maneuvers 
and  departure  from  the  target  area. 

Physical  control  of  the  RPV  by  a  human  operator  is  required  in  the  over- 
the-target  strike  phase  for  several  reasons  The  human  operator,  using 
visual  imagery  from  an  £0  sensor,  can  identify  the  target,  examine  its 
condition  (e . g .  state  of  occupancy,  damage,  etc.),  accurately  position  the 
RPV  and/or  weapon  for  attacking  the  target,  and  assess  bomb  damage 
after  weapon  release . 

This  study  assumes  &  low-altitude  (200-500  feet  above  ground  level)  terrain¬ 
following  approach  to  the  target  area.  The  RPV  is  controlled  automatically 
to  pop-up  at  a  preselected  location  and  climb  to  a  preselected  altitude,  e.g. 
1500  to  2500  feet  above  ground  level.  The  EO  sensor  is  enabled,  at  which 
time  the  Strike  Controller  begins  visual  search  for  the  target.  The  RPV 
location  at  start  of  climb  is  selected  such  that,  upon  reaching  altitude,  the 
slant- range  from  RPV  to  target  allows  adequate  time  for  target  recognition, 
go -no  go  decision,  RPV  position  correction,  weapon  lock-on  if  appropriate, 
weapon  release,  and  escape  maneuver.  Previous  multi-mission  studies 
indicate  that  this  slant- range  may  be  15,000  to  40,000  feet.  The  planned 
pop-up  range  to  target  may  vary  from  mission  to  mission,  depending  upon 
such  factors  as;  sensor  type  selected  for  mission,  weather  (particularly 
visibility  (TV)  and  humidity  (IR)),  target  characteristics  (siae,  contrast, 
sky-ground  ratio,  masking  angle),  and  ground-to-air  threat. 

Previous  studies  have  indicated  the  desirability  of  having  both  TV  arid 
FLIR  options  available  as  the  preferred  sources  of  visual  imagery  for 
various  conditions.  Either  type  of  sensor  may  be  preferable  for  a  particular 
mission,  but  there  does  not  appear  to  be  a  requirement  to  have  the  capa¬ 
bility  of  using  both  types  of  tensors  on  the  same  mission  (at  least  not 
simultaneously) . 

3. 2. 6. 2  Pop-Up 

Upon  reaching  pop-up  altitude,  the  RPV  EO  sensor  is  activated  and  trans¬ 
mission  of  video  data  initiated.  The  RPV  may  be  maintained  in  level  flight 
at  the  pop-up  altitude  until  target /aiming  point  recognition  by  the  pilot,  or 
dive  may  be  initiated  immediately.  RPV  airspeed  is  expected  to  be  cn  the 
order  of  3S0  to  600  knots .  For  this  study,  it  is  assumed  .hat  the  pre¬ 
programmed  dive  angta  is  10  degrees,  however,  the  dive  angle  can  be 
changed  during  flight  by  the  strike  controller . 
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Upon  completion  of  pop-up,  the  RPV  is  positioned  at  a  planned  location  and 
heading  such  that,  normally,  the  target  will  be  within  the  field  of  view  of 
the  EO  sensor.  The  sensor  is  turned  on  and  TV  or  IR  transmission  initiated 
automatically  when  the  RFV  has  reached  pop-up  altitude .  Digital  data  mes  - 
sages  from  RPV  to  DCF  will  be  automatically  generated  to  indicata  com¬ 
pletion  of  final  approach  climb  and  activation  of  EO  sensor. 

From  the  time  of  pop-up  and  start  of  EO  sensor  data  transmission  until 
weapon  release,  the  RPV  pilot  may  have  as  little  as  12  seconds  in  which  to 
find  the  target,  make  f.  djustments  to  RPV  heading  and  dive  angle,  aim' and 
fire  the  weapon.  Therefore,  it  is  mandatory  that  familiarization  with  the 
target  area  and  the  planned  mission  profile  be  accomplished  prior  to  Jniti- 
ation  of  the  final  approach.  Moreover,  the  Strike  Controller  should  be 
seated  at  his  console  station  with  certain  selector  switch  settings  (e.g. 
video  channel  to  be  displayed)  already  made.  When  the  RPV  approaches 
the  scheduled  pop-up  location,  an  automatic  alert  indicator  should  be  acti¬ 
vated  at  the  designated  console  and  an  alphanumeric  display  of  current 
mission  status  should  be  activated  and  undated  automatically  by  the  DCF 
computer,  based  on  comparisons  of  planned  flight  profile  with  actual  RPV 
position,  velocity,  heading,  altitude,  and  other  status  data.  The  alpha¬ 
numeric  display  cor.tvnts  should  include:  mission  number,  sensor  type, 
weapon  type,  planned  pop-up  altitude  and  slant  range  to  target,  time-to-go 
before  completion  of  pop-up,  sensor  state  (an/off,  offset  angle),  and  de¬ 
tails  of  subsequence  phases  of  the  planned  flight  profile  (e.g.  dive  angle, 
escape  maneuver,  eecohdary  target). 

The  EO  sensor  display  should  permit  superposition  of  special  symbols  e.g., 
symbols  uniquely  representing  sensor  boresight,  longitudinal  axis  of  the 
RPV,  aiming  point,  and  weapon  boresight.  A  separate  display  surface 
should  be  available  tor  the  replay  of  recorded  visual  imagery.  This  display 
should  be  positioned  to  facilitate  comparison  of  the  recorded  EO  imagery 
with  the  "live"  visual  presentation. 

y <2. 6. 3  Target  Recognition 

When  the  EO  sensor  is  activated,  the  widest  field  of  view  (FOV)  setting  will 
normally  be  in  effect.  An  RPV  sensor  with  FOV  characteristics  similar 
to  that  of  the  television  system  employed  on  the  CONDOR  missile  is  postu¬ 
lated.  This  TV  system  has  a  21  X  28  degree  search  mode  FOV,  and  a 
4.2  X  5.6  degree  truck  mode  FOV.  At  three  nautical  miles  the  width  of 
terrain  viewed  in  the  larger  POv  is  approximately  9,000  feet.  This  par¬ 
ticular  ryttem  has  only  the  two  FOV  choices;  for  the  RPV  application,  a 
mull >pi«  position  or  zoom  capability  may  be  preferable. 

The  Strike  Controller  normal.’ y  first  uses  the  wide  FOV  to  search  for  the 
target.  When  he  recognizes  ths  target,  cr  what  appears  to  be  the  target, 
he  switches  to  the  narrower  FOV  to  exarwhe  a  magnified  image  of  the 
target  in  ussier  to  confirm  target  identification  £.nd  examine  target  detail. 


« 


In  the  initial  search  for  target ,  control  of  the  RPV  normally  remains  in  the 
automatic  mode  with  AFCS  inputs  governed  by  preplanned  flight  profile  data 
The  Strike  Controller  may  slew  the  EO  s&nsor  to  search  for  the  target. 
Changes  in. sensor  pointing  angle  are  not  linked  with  aircraft  flight  control 
instructions  during  this  search  period  .  Ground-to-air'  command  signals 
are  required  to  slew  the  EO  sensor  and  to  change  the  field  of  view .  Slew 
instructions  are  generated  by  using  a  joystick  type  control  to  position  a 
marker  symbol  on  the  EO  display  in  the  direction  of  the  desired  new  sensor 
aiming  point  away  from  the  present  display  center.  Operation  of  the  slew 
control  results  in  the  automatic  generation  of  sensor  slewing  command 
signals  to  the  RPV . 

Before  switching  to  a  narrower  FOV,  the  operator  must  first  ensure  that 
the  magnified  image  is  centered  on  the  desired  location.  If  that  location 
is  not  already  at  the  center  of  the  wide  FOV  image,  the  operator  positions 
a  sensor-pointing  marker  symbol  at  the  desired  location  and  slews  the  EO 
sensor  accordingly . 

During  the  target  recognition  phase,  and  throughout  subsequent  phases  of 
over-the -target  control,  the  visual  display  presentation  must  be  maintained 
such  that  the  sensor  remains  pointed  at  and  focused  upon  the  desired  lo¬ 
cation  with  a  minimum  of  jitter  or  unintentional  motion.  Therefore,  capa¬ 
bility  for  automatic  slewing  of  the  EO  sensor  to  continue  pointing  at  a 
selected  ground  position  is  required  .  This  function  should  include;  1)  the 
capability  during  the  mission  planning  of  predetermining  EQ  sensor  asimuth 
and  elevation  such  that  the  sensor  FOV  is  centered  on  a  specified  point 
upon  pop-up,  and  2)  the  capability  of  automatically  maintaining  the  sensor 
FOV  centered  upon  an  operator-designated  point  on  the  current  image .  The 
accuracy  of  preplanned  sensor  pointing  depends  upon  a  number  of  factors  , 
particularly  navigation  accuracy. 

Sensor  slewing  to  keep  a  fixed  point  in  view  can  be  initiated  and  maintained 
by  command  messages  from  the  DCF,  or  by  self-contained  data  processing 
in  the  RPV.  The  degree  of  picture  motion  away  from  Iock*on  is  a  function 
of  the  update  rate  of  sensor  assimuth  and  elevation  changes.  An  update  rate 
of  5  times  per  second  is  postulated  for  siring  the  DCF-to-RPV  communica¬ 
tions  requirements  and  DCF  processing  loads  . 

During  over-the '•target  strike  operations,  the  RPV  pilot  needs  continuous 
access  to  the  visual  imagery  capability.  The  timing  of  his  tasks  is  such 
that  sny  detectable  interruption  of  the  visual  display  (for  example;  due  to 
time-sharing  wideband  video  communications)  would  be  unacceptable  .  This 
is  not  to  eay  that  a  con.inuous  video  transmission  is  required.  A  succes¬ 
sion  of  rapidly  updated  discrete  video  frames,  presented  in  snapshot-like 
form*  it  probably  acceptable  from  the  human  factors  standpoint.  A  priori, 
continuous  presentation  appears  preferable  for  imagery  interpretation;  the 
use  of  multiple  shnapshots  is  advantageous  r.  ainly  from  the  standpoint  of 
reducing  communications  requirements  or  increasing  AJ  protection. 
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The  data  processing  requirements  associated  with  the  use  of  television  and 
IR  sensors  depend  upon  several  factors  including;  the  sensor  character¬ 
istics,  the  choice  between  digital  and  analog  transmission  techniques, 
antijam  methods  used  in  transmission,  and  image  enhancement  techniques 
to  be  employed. 

The  requirement  for  controlling  up  to  four  RPVs  simultaneously  over  tar¬ 
gets  demands  the  ability  to  communicate  and  process  sensor  outputs  from 
as  many  as  four  RPVs  simultaneously.  The  capability  to  operate  with  a 
mix  of  sensors  is  also  required;  e.g. ,  weather  conditions  in  one  target 
area  might  dictate  the  use  of  TV,  whereas  in  another  target  area  IR  might 
be  neeecsary. 

At  the  DCF,  the  communications  processing  subsystem  should  be  capable 
of  routing  processed  EO  data  from  any  RPV  to  any  operator  station  used 
for  strike  control.  The  specific  sensor  channel  to  be  displayed  at  a  par¬ 
ticular  console  can  be  determined  by  a  selector  switch  at  that  console. 

When  sensor  data  are  routed  to  a  particular  console,  the  operator  display 
data  derived  from  processed  digital  data  link  messages  from  the  same  RPV 
should  be  routed  to  that  same  console.  Incoming  sensor  data,  after  pro¬ 
cessing,  should  be  recorded  routinely  for  subsequent  use  in  operator  fa¬ 
miliarization  for  future  missions .  Editing  and  purging  of  sensor  tapes  can 
be  performed  off-line  during  periods  of  low  mission  activity. 

The  Strike  Controller  can  use  recorded  sensor  data  to  familiarize  himself 
with  the  appearance  of  the  target  and  the  target  environment.  Prior  to  the 
launch  of  planned  missions,  he  may  spend  considerable  time  comparing 
stored  sensor  data  with  photographs,  maps,  and  descriptive  material. 
Immediately  before  controlling  an  RPV  over  the  target,  the  pilot  should 
review  key  graphic  data . 

K  '.he  Strike  Controller  does  not  see  the  target  on  the  EO  display  presenta¬ 
tion,  he  may  either  switch  to  a  narrower  field  of  view,  in  order  to  see 
greater  detail,  or  he  may  scan  adjacent  areas  in  case  the  target  was  not 
originally  in  the  sensor  FOV  upon  pop-up.  To  switch  to  the  narrower  field 
of  view  (or  use  a  zoom  capability  if  that  is  provided),  the  Strike  Controller 
could  turn  a  control  knob  to  a  setting  corresponding  to  the  desired  new  field 
of  view.  This  in  turn  would  cause  the  automatic  generation  of  a  digital  com¬ 
mand  message  to  the  RPV  that  would  be  interpreted  by  the  on-board  pro¬ 
cessor  and  converted  into  electro-mechanical  signals  actuating  the  EO  lens 
system.  To  scan  with  the  sensor,  the  Strike  Controller  must  first  inhibit 
automatic  sensor  slewing,  if  that  is  in  effect,  by  twitch  action  generating 
the  appropriate  control  m  ssage.  Scanning  is  accomplished  by  using  a 
manual  slewing  control  on  the  Strike  Operator's  console,  previously 
described.  (IJ  is  recognized  that  the  RPV  system  will  be  designed  so 
that  with  the  EO  sensor  FOV  provided,  and  the  Navigation  Accuracy 
and  target  position  error  expected,  the  probability  is  high  that  the  tar¬ 
get  will  be  in  the  FOV.  Still,  the  possibility  exists  that  the  target  will 
be  outside  the  FOV  and  the  system  should  be  designed  to  cope  with  that 
contingency. ) 
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Upon  recognizing  the  target,  the  Strike  Controller  will  reactivate  automa¬ 
tic  sensor  slewing  and  use  the  narrowest  FOV  to  examine  target  details. 

He  must  quickly  determine  if  the  target  is  suitable  for  attack  (e.g. ,  a  SAM 
site  may  be  unoccupied;  or  a  structure  may  already  have  been  destroyed  or 
heavily  damaged  by  other  forces). 

It  must  be  anticipated  that  in  some  missions  the  Strike  Controller  will  have 
difficulty'  in  recognizing  the  target.  The  RPV  at  pop-up  may  not  be  posi¬ 
tioned  at  the  exact  location  and  heading  expected  by  the  controller.  The 
target  image  may  be  at  an  unexpected  location  in  the  sensor  FOV,  or  it 
may  not  even  be  within  the  FOV.  Also,  if  the  target  is  on  the  periphery  of 
the  sensor  FOV,  it  may  disappear  from  the  FOV  before  the  controller 
identifies  it,  or  too  late  for  weapon  aiming  and  delivery.  In  any  event, 
if  the  target  is  not  engaged,  the  options  are  to  abort  the  target  or  try 
to  engage  the  target  on  a  second  pass.  The  option  selected  will  depend 
on  the  mission  requirements  and  other  tactical  factors  such  as  target 
defenses. 

if  a  second  run  on  the  target  is  selected,  the  flight  control  instructions 
required  to  turn  the  RPV  and  reposition  it  for  a  second  run  at  the  target 
can  be  preprogrammed  and  activated  by  operator  switch  actions  at  the 
console.  The  flight  profile  segments  for  this  operation  are  similar  to 
those  required  for  a  second  weapon-delivery  pass  at  the  same  target,  dis¬ 
cussed  below. 

If  the  Strike  Controller  determines  that  the  target  is  sufficiently  damaged 
or  unoccupied  to  abort  the  primary  mission,  he  would  normally  activate 
the  preplanned  flight  profile  instructions  for  an  alternate  target. 

The  selection  of  alternate  courses  of  action  is  implemented  by  presenting 
the  Strike  Controller  with  a  visual  display  of  his  alternative  choices,  in¬ 
cluding  any  priorities  established  for  these  choices,  and  a  means  of  in¬ 
dicating  to  the  DCF  processor  which  choice  is  to  be  activated.  This  func¬ 
tion  can  be  implemented  in  several  ways:  e.g.  ,  the  choices  can  be  listed 
on  an  alphanumeric  CRT  display,  with  the  selection  being  made  by  using 
a  light  pen  or  movable  cursor;  or  the  choices  could  be  selected  by  pres¬ 
sing  swltchkeys  hearing  the  appropriate  labels  (e.g.,  "proceed  to  secon¬ 
dary  target",  "start  second  pass",  etc.). 

The  automatic  processing  requirements  for  implementing  alternative  cour¬ 
ses  of  action  include  keeping  track  of  where  the  RPV  ie  in  its  planned  sched¬ 
ule  of  events,  and  of  switching  to  the  planned  flight  profile  corresponding 
to  the  alternative  branch.  The  RPV  may  not  be  at  the  pre-planned  location 
at  the  time  the  alternative  branch  is  selected  if  the  Strike  Controller  has 
been  manually  generating  flight  control  instructions  for  the  AFCS.  How¬ 
ever,  the  DCF  automatic  processor  can  determine  a  heading  (and  altitude) 
from  the  RPV  position  at  the  time  that  the  Strike  Controller  selects  the  new 
branch  that  will  bring  the  RPV  onto  the  desired  flight  profile .  This  can  be 
accomplished  by  comparing  actual  RPV  position,  heading,  and  altitude 
from  the  navigation  and  tracking  eyetem  with  the  next  segment  of  the  new 
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flight  profile,  and  computing  new  flight  control  instructions  to  get  from  the 
former  to  the  latter. 

3. 2. 6. 4  Weapon  Delivery 

Assuming  that  the  target  has  been  acquired  and  the  decision  is  to  proceed 
with  the  mission  as  planned,  the  next  major  task  is  to  aim  and  release  the 
weapon.  The  process  of  aiming  the  weapon  may  also  entail  changing  the 
RPV's  speed,  heading,  or  dive  angle. 

Specific  requirements  for  the  aiming  and  control  of  RPV  weapons  depend 
upon  weapon  type .  The  control  system  must  be  capable  of  handling  a 
variety  of  weapon  types  including;  "smart"  bombs,  rockets,  guns,  and 
'dumb"  bombs. 

Smart  bombs  have  a  self-contained  means  of  locking  onto  this  target  and 
generating  their  own  steering  directions.  Lock-on  could  be  based  on  dis¬ 
cerning  contrasting  light  patterns  in  the  target  image,  homing  on  jamming, 
or  on  detecting  radar,  laser,  or  other  energy  aimed  at  and  reflected  from 
the  target  surface.  For  this  study,  if  the  weapon  requires  an  illuminating 
source,  it  is  assumed  that  function  is  performed  by  a  different  RPV  or  air¬ 
craft  and  is  considered  as  a  separate  mission.  Requirement*  for  target- 
illuminator  RPV  missions  were  not  analyzed.  A  priori,  the  illuminator 
aiming  accuracy  and  platform  stability  requirements,  which  clearly  are 
considerably  more  demanding  than  those  for  the  RPV  visual  sensor,  would 
appear  to  be  critical  factors  in  the  use  of  drones  for  delivering  this  class 
of  weapons . 

The  dumb  bomb  contains  no  means  of  target  sensing  or  changing  its  tra¬ 
jectory  and  must,  therefore,  be  released  on  a  free-fall  trajectory  course 
that  coincides  with  the  target.  Because  the  dumb  bomb  is  a  free-fall  wea¬ 
pon,  precise  computation  of  the  release  point  is  required. 

Studies  to  date  indicate  that  the  weapon-release  computations  could  be  per¬ 
formed  either  at  the  DCF  or  onboard  the  RPV.  The  basic  advantages  and 
disadvantages  of  each  alternative  are  clear.  Remoting  the  weapon  release 
computations  to  the  DCF  would  centralize  the  function  in  a  single  processor 
and  minimize  the  on-boavd  ADP  requirements  for  the  RPV.  However,  this 
would  increase  tho  amount  of  data  to  be  transmitted  both  ways  between  DCF 
and  RPV,  and  these  communications  would  have  stringent  response  times 
and  high  repetition  rates.  Performing  the  computations  on  the  RPV  reduces 
the  communications  requirements  at  the  cost  of  requiring  increased  data 
processing  onboard  onboard  the  RPV. 


Smart  bombs  require  less  data  processing,  less  DCF-to-RPV  two-way 
communication  of  digital  messages,  and  less  stringent  requirements  for 
accurate  positioning  of  the  RPV  at  the  release  point.  The  primary  re¬ 
quirement  is  that  of  positioning  the  RPV  within  the  flight  envelope  of  the 

weapon .  . 

It  is  envisioned  that  the  basic  method  of  maintaining  the  RPV  flight  profile 
within  the  weapon  release  envelope  would  be  as  follows.  The  Strike  Con¬ 
troller  would  compare  the  actual  RPV  position  and  heading  with  a  pre- 
established  weapon- release  envelope  computed  for  the  given  target  loca¬ 
tion.  The  weapon  envelope  could  be  shown  graphically  on  the  Strike  Con¬ 
troller's  EO  display,  in  the  form  of  dashed  lines  superimposed  on  the 
sensor  imagery.  The  symbol  representing  the  boresight  of  the  RPV  would 
be  compared  with  the  outlined  weapon- release  envelope  to  determine  if 
changes  to  RPV  heading  or  dive  angle  were  required.  The  Strike  Control¬ 
ler  would  use  the  joystick  type  control  to  maintain  the  RPV  boresight  within 
the  envelope  outline.  Movements  of  the  control  to  repositon  the  boresight 
symbol  would  be  automatically  translated  into  commands  to  the  RPV  flight 
control  syatom  to  alter  the  RPV  heading  and  dive  angle.  Response  actions 
by  the  RPV  will  result  in  movement  of  the  boresight  Bymbol  position  towards 
the  desired  location  within  the  weapon- release  envelope.  (The  RPV  bore¬ 
sight  symbol  location  is  a  function  of  the  magnitudes  of  the  EO  sensor  azi¬ 
muth  and  elevation  relative  to  the  longitudinal  axis  of  the  aircraft , ) 

For  smart  bombs  having  EO  sensors  with  the  capability  of  maintaining 
lockon  automatically  when  a  target  is  designated,  the  capability  of  switch¬ 
ing  from  the  RPV  EO  sensor  to  the  weapon  EO  sensor  is  required.  The 
weapon  sensor  data  would  be  transmitted  to  the  RPV,  amplified,  and  re¬ 
transmitted  to  the  DCF  via  tine  relay  aircraft. 

Before  switching  from  the  RPV  sensor  to  the  weapon  sensor,  it  is  neces¬ 
sary  to  ensure  that  the  target  will  be  within  the  field  of  view  of  the  weapon 
sensor.  There  are  two  possible  ways  of  implementing  this.  One  way  is 
to  require  that  the  RPV  be  on  a  level  line -of- sight  course  with  the  target 
at  time  of  attempted  lock-on.  Then  the  weapon  sensor  can  be  propositioned 
with  its  boresight  identical  with  that  of  the  RPV.  The  other  method  con¬ 
sists  of  using  the  remote  slewing  capability  to  generate  command  signals 
to  the  weapon  sensor  to  point  with  an  arimuth  and  elevation  coincident  with 
that  of  the  RPV  sensor.  These  signals  could  be  initiated  by  Strike  Control¬ 
ler  switchkey  action,  but,  considering  the  limited  time  available  during 
the  final  strike  maneuver,  it  is  probably  better  to  automate  this  step,  and 
have  the  weapon  sensor  begin  tracking  along  with  the  RPV  sensor  as  soon 
as  the  pop-up  altitude  is  reached  and  the  RPV  sensor  is  turned  on.  The 
Strike  Controller  can  have  a  manual  override  capability  that  allows  him  to 
aim  either  sensor  independently. 

The  Strike  Controller  should  switch  from  the  RPV  sensor  to  the  weapon 
Sensor  prior  to  weapon  release  to  confirm  that  this  sensor  is  operative  and 
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that  the  target  is  seen.  When  he  has  the  target  in  view  on  the  weapon  sen¬ 
sor,  the  Strike  Controller  makes  adjustments  to  the  weapon  sensor  azi¬ 
muth  and  elevation  to  position  the  horesight  of  the  sensor  on  the  target. 
When  he  has  done  so ,  he  transmits  a  lock-on  command  to  the  weapon  sen¬ 
sor  by  depressing  a  switchkey. 

When  lock-on  is  achieved  by  the  weapon  sensor,  a  digital  data  message  in¬ 
dicating  automatic  lock-on  should  be  transmitted,  via  the  RPV  and  relay 
aircraft,  to  the  DCF,  where  it  would  be  routed  to  the  console  of  the  Strike 
Controller  controlling  the  mission.  Depending  upon  weapon  type,  the  lock- 
on  message  may  be  required  prior  to  weapon  release.  In  addition,  it  must 
be  established  prior  to  release  that  the  RPV  is  within  the  weapon  release 
envelope .  These  two  conditions  could  be  determined  by  an  automatic  pro¬ 
cessor;  the  actual  release  command  could  be  generated  automatically,  to 
take  advantage  of  the  computer's  more  rapid  response  capability  relative 
to  the  human  operator.  After  weapon  release,  the  weapon  will  continue 
aiming  itself,  using  its  own  sensor  data  to  update  steering  instructions . 

3.2.6. 5  Expendable  RPV 

The  discus e ion  thus  far  has  concentrated  upon  weapon  delivery  by  RPV's 
that  are  recoverable.  Another  option  is  the  use  of  expendable  RPV's  for 
delivering  explosives  by  flying  them  right  into  the  targets  .  In  this  case, 
the  requirements  for  physical  control  are  similar  to  those  of  smart  bombs . 
The  same  types  of  sensors  and  guidance  techniques  employed  on  smart 
bombs  are  applicable  to  expendable  RPV's  <  If  an  automatic  iock-on  capa¬ 
bility  is  employed,  control  requirement*  are  similar  to  those  described 
■above,  except  that  only  one  EO  sensor  is  involved.  If  an  automatic  iock-on 
capability  is  not  used,  the  essential  requirement  is  that  the  Strike  Control¬ 
ler  maintain  the  aiming  paint  on  the  target. 

Xnasm  ch  as  the  expendable  RPV  is  basically  a  "single-shot"  weapon,  It  is 
cleaxiy  desirable  to  minimize  the  cost  of  on-board  equipment,  which  means 
that  all  functions  that  can  be  performed  at  die  DCF  or  relay  aircraft  should 
r  be  allocated  to  the  expendable  RPV .  If  the  expendable  RPV  is  to  be  in- 
:luded  in  the  types  of  vehicles  to  be  controlled  by  the  DCF,  certain  altern¬ 
ative  functional  allocations  become  much  more  attractive  from  a  life-cycle 
cost  standpoint,  e*g. ,  the  use  of  sn  external  navigation  system,  such  as 
ths  range -measuring  system  described  in  subsection  2.?. 9. 

Another  candidate  weapon  system  for  delivery  by  RPV  is  a  steerable  glide 
bomb  with  an  EO  sensor  that  can  be  pointed  by  control  signals  from  a  re¬ 
mote  station.  By  pointing  the  sensor  boresight  at  the  target,  a  remote 
operator  can  steer  the  weapon  into  the  target.  The  requirement*  for  con¬ 
trol  of  this  type  of  weapon  delivery  are  essentially  identical  with  those  of 
the  expendable  drone .  The  main  additional  system  requirement  entailed  by 
this  weapon  type  is  that  there  be  the  capability  of  switching  to  the  EO  sensor 
on  the  weapon,  with  the  associated  requirements  for  capabilities  of  receiv¬ 
ing,  amplifying,  and  relaying  the  weapon  EO  imagery  via  the  RPV  and  re¬ 
lay  aircraft. 
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The  Strike  Controller'*  function*  in  the  u*e  of  rocket*  and  guns  ere  pri¬ 
marily  thoee  of  maintaining  the  RPV  ho  resight  symbol  on  the  target  or  aim¬ 
ing  point  and  firing  the  weapon*  when  within  proper  range .  The  baaic  tasks 
performed  are  similar  to  those  for  other  weapons .  The  RPV  EO  sensor 
imagery  provides  the  basic  data  needed  to  control  the  mission.  The  wea¬ 
pons  are  aimed  by  flying  the  RPV  towards  the  target  or  aiming  point  and 
fired  when  RPV -to-target  slant  range  is  within  weapon  range. 

3. 2. 6. 6  Damage  Assessment 

After  weapon  release «  the  RPV  could  be  programmed  to  take  either  of  two 
basic  courses  of  action:  1)  an  immediate  escape  maneuver  to  avoid  enemy 
ground-to-air. fire*  or  2)  a  maneuver  to  permit  damage  assessment  while 
avoiding  flying  the  RPV  through  the  weapon  blast.  If  the  latter  alternative 
is  selected*  it  would  normally  be  followed  by  an  escape  maneuver*  initi¬ 
ated  by  a  control  message  generated  by  the  Strike  Controller.  The  follow¬ 
ing  discussion  assume*  that  a  bomb  damage  assessment  maneuver  is  to  be 
made  prior  to  escape  from  the  target  area. 

After  weapon  release*  the  Strike  Controller  attempts  to  maintain  or  re¬ 
acquire  visual  contact  with  die  target,  to  assess  damage .  The  maneuver 
initiated  upon  weapon  release  to  avoid  flying  die  RPV  through  the  weapon 
blast  should  be  planned  such  that  the  RPV  resumes  a  heading  that  is  com¬ 
patible  with  maintaining  the  target  within  the  EO  sensor  FOV  long  enough 
to  determine  the  extent  of  damage  or  accuracy  of  weapon  impact.  If  pos¬ 
sible*  rates  of  turn  or  climb  should  be  such  that  the  EO  sensor  can  continue 
pointing  at  the  target  without  exceeding  die  EO  tensor  gimb&l  limit* . 

(it  was  suggested  earlier  in  this  report  that  all  incoming  EO  imagery  data 
be  recorded  automatically  for  subsequent  familiarisation.  A  capability  for 
rapid  playback  of  the  sensor  data  at  the  Strike  Controller  console  would 
have  the  further  advantage  of  giving  the  controller  a  "second  look"  at  the 
target  after  the  RPV  had  flown  beyond  the  point  where  the  target  was  within 
the  sensor  gimbal  limits .  la  some  cases,  this  could  enable  him  to  deter¬ 
mine  the  extent  of  damage  without  requiring  a  second  pass  at  the  target . ) 

The  aircraft  maneuver  after  weapon  release  can  be  either  preprogrammed 
or  manual.  If  preprogrammed,  manual  override  is  possible.  The  sensor 
astmuth  and  elsvetlon  at  completion  of  the  escape  maneuver  should  be  pre¬ 
programmed  to  maintain  the  target  within  the  FOV  while  the  aircreft  ma¬ 
neuvers  .  The  target  whould  be  relatively  easy  to  acquire  visually  at  this 
time  since  there  will  be  visible  evidence  of  an  explosion  in  the  immediate 
vicinity  of  the  target. 

Xf  damage  assessment  cannot  be  performed  during  the  initial  strike  run,  a 
Second  run  at  the  target  can  be  made .  (A  second  pass  is  always  necessary 
for  dumb  bombs . } 
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Damage  assessment  may  indicate  that  a  second  strike  should  be  made  at 
the  same  target.  If  the  RPV  is  carrying  a  second  weapon  suitable  for 
attacking  that  target  and  if  RPV  status  (fuel  primarily)  indicates  that  a 
second  strike  is  feasible  ,  the  Strike  Controller  initiates  the  preplanned 
flight  profile  that  brings  the  RPV  back  around  for  another  pass  at  the  tar¬ 
get.  The  data  processing  and  communications  requirements  here  are 
similar  to  an- route  flight  profile  command  generation.  The  main  require¬ 
ment  is  that  of  identifying  the  appropriate  branch  in  the  flight  plans,  keep¬ 
ing  track  of  the  RPV's  current  position,  and  computing  heading,  speed, 
and  altitude  commands  necessary  to  bring  the  RPV  onto  the  planned  profile 
for  that  branch . 

It  is  desirable  to  provide  the  Strike  Controller  with  the  capability  of  moni¬ 
toring  the  RPV’s  track  and  status  during  the  preparatory  maneuvers  for  a 
second  pass  on  the  target,  particularly  in  cases  where  that  second  pass  is 
unscheduled.  A  simple  geographic  tracking  display  is  suggested,  which 
could  use  tiie  same  CRT  as  that  used  to  display  the  CO  sensor  imagery. 
This  display,  in  essence,  would  be  a  stylised  map.  containing  only  essen¬ 
tial  reference  features  of  the  target  area,  and  the  scale  would  be  expanded 
such  that  the  display  encompassed  the  planned  RPV  flight  profile  for  the 
return  pass,  with  perhaps  a  2000  ft  border  to  allow  for  discrepancies  be¬ 
tween  planned  and  actual  RPV  location.  The  display  should  plot  the  RPV' a 
actual  track  (within  300  ft,  CEP),  as  determined  in  the  navigation  and 
tracking  routine,  as  well  as  the  planned  track  for  the  second  run.  This 
display  would  give  the  Strike  Controller  a  visual  indication  of  the  time  re¬ 
maining  before  the  next  pop-up,  as  well  as  an  indication  of  the  probable 
location  and  heading  of  the  RPV  at  pop-up.  The  use  of  the  EO  sensor  for 
visual  checkpoints  during  the  second-pass  preparatory  turns  and  climb 
may  also  be  advantageous  here. 

3. 2. 6. 7  Summary  of  Command/Reply  Link  Data  Loads 

This  subsection  summarises  communications  load  factors  derived  in  pre¬ 
ceding  subsections  of  3,2.6  for  the  command/reply  link  in  over-the-target 
strike  control.  Table  Ill.  2-5  presents  the  estimated  message  length  and 
average  rate  of  transmission  for  each  type  of  message  content  transmitted 
from  DCF  to  RPV  and  from  RPV  to  DCF,  respectively. 

In  the  DCF-to-RPV  portion  of  the  table,  items  10  through  14  represent 
DCF-computer-generated  flight  control  instructions.  These  instructions 
would  be  generated  in  over-the-target  strike  control  when  the  RPV  is  dis¬ 
engaged  from  stored  flight  profile  data.  An  alternative  implementation 
would  be  to  allocate  to  the  RPV  on-board  processor  the  interpretation  of 
EO  senior  slewing  commands  and  their  translation  into  autopilot  setting 
changes.  For  purpose*  of  this  study,  it  is  postulated  that  this  function  is 
performs d  by  the  DCF  computer. 

From  Table  ID.  2-5,  the  peak  DCF-to-RPV  message  rate  for  data  bits, 
a*  opposed  to  overhead  bits  for  synchronization,  etc.  ,  is  approximately 
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Table  111,  2-5.  Digital  Data  Messages  OTT  Strike  Control 


DCF-to-RPV  Message  Content 

Length 

Estimated 
Average  Rate 

1.  Activate /Deactivate  RFV  sensor 

4  per  mission 

2,  Engage /Disengage  RPV  sensor 

i 

6  per  mission 

with  autopilot 

■ 

3,  Change  RPV  sensor  FOV  (Zoom) 

B9 

20  per  mission 

4.  Activate/Deactivate  weapon  sensor 

raa 

1  per  mission 

5.  Slew  RPV  sensor  and/or  weapon 

30  bits 

5  per  second 

sensor 

6.  Activate /Deactivate  Terrain  Following 

1  bit 

2  per  mission 

7,  Change  RPV  sensor  mode  * 

1  bit 

6  per  mission 

8,  Lock -on  weapon  sensor 

1  bit 

1  per  mission 

9.  Release  weapon 

1  bit 

1  per  mission 

10,  Heading 

1 2  bits 

5  per  second 

11.  Speed 

1 0  bits 

5  per  second 

12.  Altitude 

16  bits 

5  per  second 

13.  Altitude  rate 

5  bits 

5  per  second 

14.  Turn  rate 

5  bits 

5  per  second 

15.  Engage/Disengage  stored  profile 

1  bit 

2  per  mission 

« Automatic  slewing  or  manual  control  - 

not  required  if  all  slewing 

instructions  are  generated  at  the  DCF. 

Estimated 

RPV-to-DCF  Message  Content 

Length 

Average  Rate 

1 .  RPV  at  final  approach  altitude 

1  bit 

1  per  mission 

2.  RPV  sensor  on/ off 

1  bit 

2  per  mission 

3.  Flight  control  status 

2  bits 

10  per  mission 

4.  Weapon  tensor  activated 

1  bit 

1  per  mission 

S,  RPV  sensor  esimuth  and  elevation 

30  bits 

5  per  second 

6,  RPV  sensor  mode 

1  bit 

7  per  mission 

7,  Weapon  sensor  locked -on 

1  bit 

l  per  mission 

8.  Weapon  released 

1  bit 

1  per  mission 

9.  Altitude 

1 6  bits 

1  per  second 
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Table  HI.  2-5.  Digital  Data  Messages  OTT  Strike  Control  (coat) 


RFV-to-DCF  Message  Content 

Length 

Estimated 
Average  Rate 

10,  Airspeed 

10  bits 

1  per  second 

11.  Dive  Angle 

11  bits 

1  per  second 

12.  Heading 

12  bits 

1  per  second 

13.  Roll  attitude 

11  bits 

1  per  second 

14.  LORAN  TDF 

40  bits 

l  per  second 

15,  Fuel  Status 

1 1  bits 

1  per  second 

400  bp* .  If  one  allows  again  aa  many  bits  for  addressing,  synchronisation, 
etc. ,  the  total  peak  data  rate  from  the  DCF  to  one  RPV  over -the -tar get 
would  be  approximately  800  bps . 

In  the  RPV -to -DCF  portion  of  Table  III, 2-5,  items  9  through  13  are  post¬ 
ulated  to  be  used  by  the  DCF  computer: 

a.  Aa  inputs  for  generating  flight  control  instructions  to  accur¬ 
ately  position  the  RPV  during  pop-up  and  final  dive  at  the 
target  (when  not  under  manual  control  by  the  Strike 
Controller). 

b.  To  make  necessary  computation#  for  display  generation 
(e.g. ,  to  locate  RPV  boresighf  relative  to  center  of  the 
EO  sensor  field  of  view,  to  determine  RPV  relation  to 
weapon- re lease  envelope,  etc.). 

As  discuassd  in  subsection  3.2.3,  use  of  LORAN,  with  the  RPV  position- 
fix  computation*  demoted  to  the  DCF,  is  postulated  as  a  baseline  naviga¬ 
tion  system.  Item  14  of  the  table  represents  LORAN  time -difference -fix 
data  used  in  the  RPV  position  fixing  computations.  The  higher  update  rate 
(once  per  second  for  the  over-the-target  portion  of  the  mission,  including 
the  leg  lust  prior  to  pop-up,  vs,  once  per  10  seconds  enroute),  in  conjunc¬ 
tion  with  track  smoothing  and  flight  profile  correction  computations,  will 
reduce  navigation  error  at  the  start  of  target  acquisition. 

On  the  basis  of  this  table,  the  peak  RPV-to- DCF  message  rate  for  data 
bits  is  approximately  2 SO  bps ,  If  one  also  allows  250  bps  for  overhead, 
total  peak  rate  for  one  RPV  to  DCF  would  be  500  bps . 

As  mentioned  earlier  in  this  report,  additional  digital  data  required  for 
remoting  gravity-drop  weapon  release  computations  st  the  DCF  were  not 
estimated.  The  above  estimates  also  do  not  include  communications  re¬ 
quirements  for  video  or  IR  data,  which  were  not  estimated  in  this  study. 
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3. 2. 6. 8  Operator  Requirements,  Operator  Facilities,  and  ADP  Support 
for  Over -the -Target  Control 

The  nature  of  the  over-the-target  RPV  control  function,  with  its  demand 
for  full  operator  attention  and  quick  response,  requires  that  a  Strike  Con¬ 
troller  concentrate  on  one  mission  at  a  time.  Therefore,  to  meet  the 
operational  requirement  for  simultaneous  control  of  four  over-the-target 
phases  simultaneously,  four  separate  Strike  Controller  stations  are 
required. 

At  a  minimum,  each  station  must  include: 

a.  A  dynamic  display  capability  for  presenting  the  EO  sensor 
imagery  (TV  and  IR  are  prime  candidates,  but  both  are  not 
used  simultaneously  on  the  same  RPV). 

b.  A  means  of  superimposing  and  separately  controlling  the 
movement  of  special  symbols  on  the  EO  image. 

c.  A  dynamic  display  of  alpha -numeric  data  on  RPV  flight 
profile  and  status  and  computer -generated  operator  prompts 
and  alerts. 

d.  Operator  controls  that  enable  the  generation  of  command 
messages  to  the  RPV  governing  flight  profile,  EO  sensor, 
weapon  sensor,  and  weapon  release. 

A  situation  display  of  the  type  defined  in  subsection  3. 2.  $.4  for  enroute 
control  is  also  required  at  the  Strike  Controller  Station.  In  addition,  the 
capability  of  recording  and  ;  layback  of  EO  sensor  imagery  appears  highb' 
desirable.  Use  of  a  separate  display  surface  for  playback  of  recorded  oata, 
positioned  to  facilitate  comparison  with  live  imagery,  would  aid  U*  recogni¬ 
tion  of  targets  and  visual  checkpoints. 

A  number  of  AJDP  support  requirements  for  ov r-the-targei  control  have 
been  defined,  and  a  tentative  allocation  of  ADP  functions  to  DCF  and  RFP'v 
has  been  suggested.  These  are  summarized  in  Tabic  111.2-6. 

The  DCF  ADP  functions  for  over-the-target  strike  control  must  be  accom¬ 
plished  for  up  to  four  RPV's  simultaneously,  while  also  performing  the 
in-route  processing  functions  for  as  many  an  16  additional  RPV's.  How¬ 
ever,  Table  111.2-6  does  not  include  additional  functions  required  for 
weapon  release  computations,  which  would  be  required  for  o:her  than 
"smart  bombs." 
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Table  III, 2-6  ADP  Functional  Requirements  for  OTT  Strike  Control 


DCF  ADP  Functions 


1.  Display  generation  and  control/s  witchkey  interpretation,  4  Strike 
Controller  Consoles . 

2.  RPV  position -fixing  and  tracking. 

3 .  Integrating  RPV  tracking  data  with  flight  control  data  to  project 

RPV  future  positions . 

4.  Comparing  actual  track  with  planned  flight  profile  and  generating 
corrective  flight  control  messages  or  operator  alerts. 

5.  Determining  if  RPV  flight  path  intersects  weapon- release  envelope. 

6.  Determining  projection  of  aircraft  longitudinal  axis  on  £0  sensor 
image  and  positioning  symbol  on  visual  display  accordingly. 

7 .  Selecting  operator-designated  branch  of  flight  profile  and  up¬ 
dating  RPV  on-board  flight  profile. 

8.  Command  message  generation,  addressing,  formatting. 

9.  Reply  message  processing,  routing. 


RPV  ADP  Functions 


1.  Perform  time-difference  measurements  on  raw  LQRAN  signals. 

2.  Store  flight  profile  data  transmitted  from  DCF  before  launch 

and  while  airborne. 

3.  Translate  stored  flight  profile  into  flight  control  settings  for 
autopilot  at  scheduled  time . 

4.  Process  incoming  command-messages  and  generate  appropriate 
electro-mechanical  signals. 

5.  Generate  and  format  reply  messages  on  RPV,  sonsor,  and 
weapon  statue,  exceptional  conditions,  flight  parameters. 

6 .  Translate  incoming  flight  control  messages  into  flight  control 
settings  for  autopilot . 

7.  Translating  operator  changes  to  EO  sensor  azimuth  and  eleva¬ 
tion  and  other  control  settings  into  aircraft  weapon  starring 
commands . 
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3.3 


RPV  FORCE  COMMAND  AND  CONTROL  FUNCTIONS 


3.3.1  Introduction 

3. 3. 1. 1  RPV  System  Factors  Impacting  Force  Command  and  Control 

The  general  requirements  for  command  and  control  of  the  RPV  force  are 
the  same  as  for  manned  systems.  The  force  objectives  must  be  developed 
for  a  mixed  force  or  for  a  pure  RPV  force.  Mission  requirements  must  be 
established,  resources  assigned,  and  missions  planned.  In  the  execution 
phase,  the  operation  must  be  monitored  and  adjustments  made  to  most  ef¬ 
fectively  achieve  the  force  objectives  in  a  dynamic  environment.  There  are, 
however,  a  number  of  RPV  features  that  significantly  impact  Command  and 
Control  functions.  Table  HI.  3-1  summarizes  these  RPV  system  features 
and  indicates  the  general  impact  of  these  features  on  Command  and  Control. 
The  specific  considerations  and  assumptions  are: 

a.  Attrition  Factors:  A  fundamental  premise  is  that  the  RPV 
system  it  designed  to  be  cost  effective  at  sustained  attrition 
rates  that  are  unacceptable  for  manned  systems.  Th4  con¬ 
sequence  this  ..-remise  is  that  for  a  mixed  force,  assuming 
mission  objectives  can  be  achieved  using  either  EPV'a  or 
manned  aircraft,  threat  assessment  (probably  loss)  becomes 
e  more  important  criteria  in  the  weapon  selection  function. 
When  a  weapon  system  has  been  selected,  planning  develops 
penetration  and  attack  tactics  that  provide  acceptable  assur¬ 
ance  that  the  mission  objective  will  be  achieved,  while  con¬ 
currently  maximizing  the  survivability.  This  consideration 
is  applicable  to  manned  systems  and  RPV  systems  alike. 

b.  Low  Altitude  Penetration:  The  RPV  is  designed  for  low  altitude 
penetration  and  more  frequent  high  G  measures  are  acceptable 
than  is  true  for  manned  aircraft.  However,  without  a  pilot 

the  RPV  hat  no  capability  to  sense  real  time  flight  hazards 
and  to  avoid  them  (except  for  its  terrain  following  capability). 
The  consequence  is  that  route  safety  must  be  analysed  and 
made  a  part  of  the  preprogrammed  flight  profile, 

e,  Precision  Flight:  While  the  requirement  to  preprogram  the 
RPV  flight  profile  introduces  exacting  requirements  for  route 
planning,  the  capability  of  the  RPV  to  follow  a  preprogrammed 
flight  profile  and  schedule  introduces  potential  sophistication 
in  the  coordination  of  primary  and  support  mission*.  There¬ 
fore,  requirements  which  exploit  coordinated  mission  planning 
are  introduced. 

d.  Communi cations  Requi rement * :  The  requirement  for  semi- 
continuous  communications  with  the  RPV’s  enroute  and  con¬ 
tinuous  communications  during  the  attack  phase  is  affected  by 
the  low  altitude  flight  profile  of  the  RPV.  This  can,  in  many 
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Table  III.  3-L  F  PV  System  Features  Impacting  Force  C&C 


RPV  System  Design  Features 
Impacting  Force  C  &  C 

.  i 

General  Effect  on  Force  | 

Command  St  Control 

Attrition  -  System  is  designed 
to  be  cost  effective  at  highe. 
attrition  rates  (vis-a-vis 
manned  system). 

Mixed  Force  -  Threat  assessment, 

?.  more  important  criterion  in 
weapon  selection. 

Pure  RPV  Force  -  Weapon  selection 
similar  to  that  for  manned  systems. 

Low  Altitude  Penetration 
following  preprogrammed  flight 
profile. 

All  details  affecting  route  safety 
evaluated  in  detail  and  every 
detail  of  the  fpght  profile 
preprogrammed. 

Precision  Flight  -  The  RPV 
will  follow  exactly  a  pre¬ 
programmed  flight  profile 

and  schedule, 

Exacting  requirements  to  plan 
coordinated  missions. 

Communications  -  Requirements 
to  maintain  communications 
through  an  airborne  relay  to 
maintain  physical  control. 

Exacting  requirements  for  planning 
relay  station  location(s)  com-, 
patihle  with  RPV  routes  and 
targets. 

Flight  Profile  Preprogramming 
Requirements. 

Requirement  to  generate  a  flight 
profile  for  insertion  into  the 

RPV  System , 

situations,  introduce  terrain  masking  of  the  line  of  sight  com¬ 
munications  links;  further  onemy  jamming  can  be  expected. 
These  factors  combine  to  itUroduce  new  and  relatively  complex 
requirements  for  communications  planning, 

e.  Flight  Profile  Programming  Requirements:  An  operational 
assumption  is  that  tSe  ' response  capability  of  the  RPV  system 
mutt  be  comparable  to  that  of  the  manned  systems.  The  con¬ 
sequence  is  that  manual  procedures  alone  cannot  provide  the 
required  response  times.  Automated  aids  to  route  profile 


3-39 


planning  a  capability  to  automatically  convert  a  preplanned 
flight  profile  into  preprogrammed  flight  control  instructions  is 
required. 

Table  IXE.  3-1  summarizes  these  ItFV  system  i'earares  and  indicates  their 
general  impact  on  Command  and  Control. 

3.?.  1,2  Force  Command  and  Control  Functions 

At  the  highest  command  level,  force  Command  and  Control  relates  to  the 
planning  and  management  of  force  resources  to  achieve  the  overall  force 
objective.  At  lower  levels,  it  relates  to  planning  and  managing  a  part  of 
the  force  to  achieve  some  specific  objectives  which  have  been  assigned. 

Within  the  framework  of  the  tactical  control  systems  which  have  evolved, 
the  Tactical  Air  Control  Center  {TACC)  of  the  Tactical  Air  Control  System 
plans  the  operations  for  the  total  force.  Assignments  are  made  in  the  daily 
frag  order.  The  tasked  units,  wings  and  independent  squadrons,  develop  the 
detailed  plans  required  to  assign  specific  resources,  and  to  execute  the 
mission. 

Table  III.  3-2,  Fores  Command  and  Control  Functions,  lists  the  command 
and  control  functions  related  to  mission  planning,  monitoring,  and  control 
as  they  are  normally  identified.  The  functions  under  "total  force  planning” 
are  those  allocated  to  the  TACC  Current  Plans  division.  Those  under  "unit 
planning",  are  the  planning  functions  normally  assigned  to  the  tactical  units. 
As  tabulated,  there  is  a  functional  overlap  between  "total  force  planning" 
and  "unit  planning". 

TACC  planning  for  assignment  cannot  be  accomplished  without  considering 
viable  over -the -target  tactics,  enroute  threats  and  mission  support  require¬ 
ments.  These  same  factors  are  significant  considerations  in  detailed  mis¬ 
sion  planning  for  execution.  Whets  one  considers  ADP  support  to  mission 
planning,  certain  trade-offs  are  obvious.  More  detailed  planning  could  be 
done  at  the  TACC  with  reduced  requirements  to  plan  at  the  unit  level.  Al¬ 
ternatively,  it  \s  desirable,  for  several  reasons,  to  allocate  detailed  plan¬ 
ning  to  the  unit  assigned  responsibility  to  execute  the  plan.  These  reasons 
involve  operational  considerations  that  are  not  addressed  in  this  study.  The 
analysis  that  follows  presumes  that  the  force  has  beer  apportioned  and  individ 
ual  mission  objectives  have  been  established.  The  requirements  to  develop 
detailed  plans  are  addressed  in  this  study.  However,  no  distinction  is  made 
between  planning  for  assignment  (TACC)  and  planning  for  execution  (tactical 
unit). 

The  sequence  in  which  the  planning  functions  are  listed  on  Table  III,  3 '2  is 
the  sequence  in  which  the  functions  are  typically  executed  in  the  planning 
cycle.  The  text  that  follows  addresses  the  planning  functions  in  reverse 
order,  starting  with  the  requirement  to  convert  a  planned  mission  profile 
into  the  format  required  for  physical  control.  Route  planning  and  the  inter¬ 
related  requirement  to  plen  the  communications  relay  missions  are  then 
addressed.  Finally,  that  planning  required  to  plan  over -the -target,  or 
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Table  III.  3-2.  Force  Command  and  Control  Functions 


TOTAL  FORCE  PLANNING: 


Requirements  analysis 

Resource  analysis 

Force  apportionment 

Detailed  planning  for  assignment 

Frag  order  generation  and  distribution 


UNIT  PLANNING: 


Detailed  mission  planning  for  execution: 

o  Select  or  validate  weapon  selection,  configure  carrier  (A/C,  RPV) 
o  Select  or  validate  sensor  selection,  configure  carrier  (A/C,  RPV) 
o  Develop  over -the -target  or  on-station  tactics  (A/C,  RPV) 
a  Plan  mission  route  profile  and  schedule  (A/C,  RPV) 
o  Plan  communications  relay  operations  (RPV's  only) 
o  Convert  RPV  mission  profile  into  that  format  required  for 
physical  control  (RPV's  only) 


on- eta ti on,  operation*  ia  described.  This  reverse  order  of  presentation  is 
selected  because  the  unique  features  of  the  RPV  affect  most  directly  the 
route  profile,  communications  relay  planning,  and  precoding  functions.  As 
one  proceeds  "up  the  table"  of  functions,  away  from  very  detailed  planning, 
the  impact  of  RPV  on  planning  functions  is  generally  smaller. 

3.3.2  Flight  Profile  Coding 

3. 3. 2. 1  Introduction 

It  is  a  requirement  of  the  RPV  system  that  the  preplanned  flight  profile  be 
converted  into  a  set  of  coded  instructions  that  can  be  inserted  into  the  RPV. 
The  instructions  coded  must  be  such  that  the  power  setting  or  fuel  flow  for 
engine  control,  and  the  settings  for  the  flight  control  surfaces,  can  be  imple¬ 
mented  by  the  on-board  AFCS  and  such  that  execution  of  the  instruction  will 
result  in  the  desired  route  profile.  The  AFCS  combines  the  instructions 
with  sensed  information  concerning  deviation  from  the  desired  flight  attitude 
(due  to  atmospheric  turbulence,  for  example)  to  produce  continuous  aircraft 
control.  Planned  variation  of  the  flight  path  parameters  are  accomplished 
by  implementing  the  next  instruction  at  an  appropriate  time. 

This  subsection  describes  the  process  that  converts  a  planned  flight  profile 
into  code  that  can  be  inserted  into  the  RPV  Bystem.  Subsection  3.3.3, 

Route  Planning,  describes  in  detail  the  procedure  for  generating  the  profile 
itself.  Generally,  route  planning  for  RPV's  is  similar  to  route  planning  for 
manned  aircraft.  The  route  profile  is  specified  in  terms  of  position,  flight 
altitude,  direction  of  flight,  and  power  setting.  Segments  such  as  launch, 
climb,  and  descend  can  be  specified.  A  controlling  schedule  time  is  input 
and  from  this  controlling  time  all  schedule  times  are  derived. 

The  specific  instructions  to  be  coded  and  the  processing  required  to  convert 
a  flight  profile  into  a  set  of  coded  instructions  depend  upon  a  number  of  sys¬ 
tem  factors. 

To  facilitate  the  following  discussion,  several  definitions  are  presented. 

ROUTE/PROFILE  —  The  flight  path  which  is  to  be  traversed  by  the 

RPV,  the  flight  altitude,  and  the  power  mode. 

LEG  —  A  portion  of  the  route /profile  which  connects 
two  adjacent  check  points. 

FLIGHT  MODE  —  A  description  of  the  manner  in  which  the  air¬ 
craft  is  changing  its  position  and/or  velocity. 
Examples  are;  climb,  cruise,  and  accelerate. 

With  reference  to  the  above  definitions,  a  leg  is  composed  of  a  sequence  of 
flight  modes,  end  a  route  profile  is  a  sequence  of  legs.  At  each  level,  the 
elements  are  linked  together  by  using  the  terminal  point  of  one  element  as 
the  initial  point  of  the  nett. 
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An  implementation  concept  that  very  significantly  affects  the  processing 
required  to  convert  the  planned  profile  into  a  set  of  coded  instructions  is 
the  concept  of  preprogrammed  flight  segments.  In  its  simplest  sense,  the 
concept  is  that  any  flight  profile  can  be  conceived  of  as  consisting  of  a  num¬ 
ber  of  standardized  legs  appropriately  chained  together. 

The  effect  of  the  execution  of  a  preplanned  leg  is  always  to  alter  the  state  of 
the  aircraft  in  a  fixed  manner  relative  to  its  initial  point.  For  example, 
launch  might  move  the  RPV  from  its  pad  to  a  point  down  range  at  an  altitude 
of  15,  000  feet.  The  specific  position  would,  be  determined  by  the  position  of 
the  launch  site,  a  specified  heading,  and  RPV  parameters. 

The  following  subsections  describe  the  elements  at  each  level  of  route/ 
profile  description.  The  presentation  is  from  the  bottom  up.  That  is,  the 
flight  modes  are  described  first,  then  the  legs,  and  finally  a  route /profile. 

3.  3. 2.  2  Flight  Modes 

The  set  of  flight  modes  consist  of: 

•  ACCELERATE 

•  CLIMB 

•  CRUISE 

•  DESCEND 

•  LAUNCH 

•  RECOVER 

•  REMOTE 

•  TERRAIN 

•  TRIGGER 

•  TURN 

The  effect  of  executing  a  portion  of  the  route/profile  in  any  of  the  above  modes 
is  to  change  the  state  vector  of  the  RPV,  The  state  vector  consists  of  at 
least  the  following: 

•  RPV  Type 

•  Position  (latitude /longitude) 

•  Altitude 

•  Heading 
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•  Mach  Number 

•  Gross  Weight 

0  Fuel  State 

0  Drag  Index 

0  Elapsed  Time 

The  state  vector  of  the  RPV  then  is  a  detailed  description  of  its  performance 
and  characteristics  at  any  instant  of  time.  This  state  vector  is  used  as  a 
basis  for  describing  changes  to  be  implemented  in  the  next  flight  mode. 

The  motion  of  the  RPV  in  any  flight  mode  will  result  in  a  change  in  the  state 
vector.  The  following  variables  will  always  change:  position,  gross  weight, 
fuel  state,  and  elapsed  time.  The  other  variables  will  change  while  the  RPV 
is  executing  specific  flight  modes.  Table  III,  3-3  presents  the  flight  modes, 
any  supplementary  input  parameters  required,  and  state  variables  (other  than 
those  that  always  change)  which  are  affected.  Each  flight  mode  is  also  de¬ 
scribed  in  the  following  paragraphs. 

Accelerate:  The  accelerate  flight  mode  is  used  to  increase  or  decrease  the 
mach  number  of  the  RPV  while  the  heading  and  altitude  remain  constant.  At 
the  point  of  initiation  of  the  mode  the  mach  number  to  be  achieved  and  a  throt¬ 
tle  setting  (max  or  mil)  must  be  specified. 

Climb;  The  climb  flight  mode  is  used  to  increase  the  altitude  of  the  RPV 
while  the  heading  remains  constant.  At  the  poin*  of  initiation  of  the  mode  it 
is  necessary  to  specify  the  desired  altitude  and  a  throttle  getting  (mil  or  max). 
The  throttle  setting  determines  the  appropriate  climb  schedule  which,  in  turn 
affects  the  distance,  fuel,  and  time  required  to  climb  and  determines  the 
mach  number  when  altitude  is  achieved. 

Cruises  The  cruise  flight  mode  is  used  when  the 'RPV  is  to  maintain  a  con¬ 
stant  heading,  altitude,  and  mach  to  traverse  a  specified  area.  It  is  used 
for  straight  legs,  and  the  distance  to  be  traversed  must  be  specified. 

Descend:  The  descend  flight  mode  is  used  to  decrease  RPV  altitude  while 
maintaining  a  constant  heading.  At  the  point  of  mode  initiation  it  is  neces¬ 
sary  to  specify  the  dive  angle  or  rate  of  descent  and  altitude  to  achieve 
these  maneuvers.  The  appropriate  descend  schedule  is  then  determined. 

This  includes  mach  number  at  the  terminal  point  of  the  flight  mode. 

Launch:  The  launch  mode  is  used  to  initiate  the  flight  of  the  RPV.  It  changes 
the  state  of  the  vehicle  from  its  initial  condition  to  an  independent  airborne 
vehicle.  Whether  the  RPV  U  initially  on  a  pad  or  carried  by  another  aircraft 
significantly  affects  the  launch  mode;  however,  in  either  case,  the  primary 
change  which  occurs  is  that  the  RPV  becomes  an  independent  airborne  entity. 


3-44 


Table  III.  3-3.  Flight  Mode  Required  Inputs  and  Variables 


Flight  Mode 

Supplementary 
Input  Variables 

Distinguishing 

Variable 

Change 

Termination 

Condition 

Accelerate 

Throttle  Setting 

Mach  Number 

Mach  Achieved 

Climb 

Throttle  Setting 

Altitude 

Altitude 

New  Altitude 

Mach  Number 

Achieved 

Cruise 

None 

None 

Distance 

Achieved 

Descend 

Throttle  Setting 

Altitude 

Altitude 

New  Altitude 

Mach  Number 

Achieved 

Launch 

Heading 

Altitude 

Initial  Burn 

Heading 

Complete 

Recover 

None 

Close  Down 

Close  Down 

Remote 

Sensor  Activate 

Direct  Operator 

Operator 

Control 

Command 

Terrain 

None 

Heading 

Distance 

Altitude 

Achieved 

Turn 

Heading 

Heading 

Heading 

Radial  Acceleration 

Achieved 

The  result  of  a  launch  mode  is  to  place  the  RPV  at  its  first  position  and  es¬ 
tablish  its  first  state  vector  values.  (It  is  necessary  to  state  the  desired 
heading. ) 

Recover;  The  recovery  mode  is  used  to  terminate  the  flight  of  the  RPV, 
Recovery  can  be  by  parachute  which  is  the  baseline  system.  Alternatively, 
runway  recovery  or  other  recovery  means  are  possible.  In  any  event, 
recovery  is  a  process  initiated  at  the  end  point  of  the  return-to-base  flight 
segments.  Recovery  is  initiated  by  a  handover  to  recovery  control.  Recov¬ 
ery  maneuvers  are  not  precoded,  except  for  'triggered'  responses  such  as 
deploy  parachute. 

Remote;  The  remote  flight  mode  is  used  when  it  is  necessary  for  the  RPV  to 
be  under  the  direct  control  of  an  operator.  The  mode  may  be  initiated  only  by 
a  real  time  command  since  it  requires  that  the  operator  be  in  communication 
with  the  RPV,  However,  as  a  safeguard  against  countermeasures,  such  com¬ 
mands  will  only  bs  recognised  during  designated  periods  and  when  accompan¬ 
ied  by  appropriate  lock  keys.  This  mode  allows  an  update  or  modification  of 
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the  stored  commend  stack  as  well  as  the  ability  to  maneuver  the  aircraft  in 
very  near  real  time.  It  can  be  used  to  adjust  route/profiles  for  deviations 
from  planned  schedules,  and  for  control  of  the  RPV  during  critical  mission 
times. 

This  mode  is  unique  in  that  it  makes  reference  to  other  bommands  in  the 
stored  route /profile.  Three  command  numbers  are  specified  as  parameters. 
The  first  is  the  command  to  execute  in  case  file  operator  does  not  acquire 
the  RPV,  second  is  the  command  to  execute  when  the  operator  returns  com¬ 
mand  to  the  RPV,  and  the  third  is  the  command  to  execute  in  the  event  of  a 
communications  interruption  during  a  period  of  operator  control. 

Terrain:  The  terrain  (following)  flight  mode  is  used  when  the  aircraft  is  to 
maintain  a  specified  altitude  relative  to  the  terrain  which  it  is  traversing. 

The  heading  is  to  be  maintained.  It  is  necessary  to  specify  the  relative  al¬ 
titude  to  maintain,  and  the  total  length  in  distance  of  the  flight  mode. 

Trigger:  The  trigger  mode  is  used  to  change  the  flight  mode  in  response  to 
conditions  which  are  sensed  on  the  RPV.  Examples  are: 

s  On  weapon  release,  the  next  flight  segment  is  initiated;  which 
could  be  escape  or  bomb  damage  assessment. 

•  If  failure  of  the  terrain  following  radar  is  sensed,  a  climb 
maneuver  is  initiated. 

•  An  available  option,  if  radar  homing  and  warning  is  detected, 
is  that  jinking  can  be  initiated. 

Turn:  The  turn  mode  is  used  to  change  the  heading  of  the  RPV.  At  the  initial 
point  of  the  mode,  it  is  necessary  to  specify  the  new  heading  and  the  radial 
acceleration  of  the  turn. 

3. 3. 2. 3  Route  /Profile  Legs 

The  set  of  leg  types  consists  of: 

•  CLIMB 

•  CRUISE 

•  DESCEND 

•  LAUNCH 

•  LOITER 

•  TERRAIN 

•  DELIVERY 
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Each  leg  type  combines  a  sequence  of  flight  modes  into  a  pattern  which, 
when  executed,  results  in  the  RPV  traveling  from  the  initial  check  point 
of  the  leg  to  the  terminal  check  point  of  the  leg,  according  to  the  character¬ 
istics  of  the  leg  type.  In  essence,  a  leg  type  is  a  precoded  set  of  flight 
modes  with  certain  parameter  values  not  specified.  When  the  parameters 
are  specified,  the  leg  type  becomes  a  specific  sequence  of  flight  modes. 

Leg  types  are  only  used  as  a  convenience  to  the  planner  and  are  trans¬ 
lated  during  the  coding  process  into  their  corresponding  set  of  flight  mode 
sequences  before  insertion  into  the  RPV. 

For  each  leg  type,  the  initial  conditions  are  the  terminal  conditions  of  the 
preceding  leg.  Parameter  values  specified  are  values  to  be  attained  and 
maintained  during  the  leg.  The  following  paragraphs  describe  each  of  the 
leg  types. 

CLIMB:  Whenever  the  planner  wishes  to  increase  the  altitude  of  the  RPV 
between  two  check  points  he  defines  a  CLIMB  leg.  The  general  character¬ 
istics  of  a  CLIMB  leg  are;  1)  a  geographical  separation  of  the  initial  and 
terminal  check  points,  and  2)  an  increase  in  altitude  between  the  initial  and 
terminal  check  point.  In  order  to  define  a  specific  CLIMB  leg  the  following 
parameters  must  be  specified: 

•  Position  of  the  terminal  check  point  of  the  leg. 

•  Mach  number  at  the  final  check  point  (if  not  present,  a  default 
is  made  to  an  appropriate  value  in  the  climb  schedule). 

•  Throttle  setting  to  use  for  the  climb. 

A  CLIMB  leg  type,  for  which  the  throttle  setting  for  climb  yields  a  speed  at 
the  end  of  climb  different  from  the  Mach  number  of  the  final  check  point, 
requires  a  flight  mode  of  accelerate  or  decelerate  to  resolve  the  difference. 
An  error  condition  arises  if  the  final  check  point  is  not  compatible  with  the 
heading  specified  at  the  initial  check  point  of  the  leg. 

CRUISE:  The  distinguishing  characteristics  of  a  CRUISE  leg  are:  1)  a  geo¬ 
graphical  separation  of  the  initial  and  terminal  check  points,  and  2)  no  alti¬ 
tude  change  between  check  points. 

In  order  to  define  a  specific  CRUISE  leg  it  is  necessary  to  specify  tho  fol¬ 
lowing  parameters. 

•  Position  of  the  final  check  point. 

•  Mach  number  for  CRUISE. 
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If  the  heading  of  the  RPV  at  its  initial  check  point  is  not  consistent  with  the 
location  of  its  terminal  check  point  the  CRUISE  leg  includes  a  turn  mode  to 
a  cruise  mode.  Similarly,  if  the  Mach  number  is  different  at  the  initial  and 
terminal  check  points  an  accelerate/decelerate  mode  is  added  to  the  cruise 
mode.  Any  mode  other  than  cruise  is  implemented  at  the  start  of  the  leg. 

An  error  condition  arises  if  the  altitude  of  the  initial  and  terminal  check 
point  are  different. 

DESCEND:  The  distinguishing  characteristics  of  a  DESCEND  leg  are: 

1)  a  geographical  separation  of  the  initial  and  terminal  check  points,  and 

2)  a  decrease  in  altitude  from  the  initial  to  the  terminal  leg. 

In  order  to  define  a  specific  DESCEND  leg  it  is  necessary  to  specify  the 
following  parameters: 

•  Position  of  the  terminal  check  point. 

•  Constant  air  speed  value  for  descent  (if  not  present,  a  default 
is  made  to  an  appropriate  value). 

A  DESCEND  leg  type,  for  which  the  constant  air  speed  specified  for  the 
descent  is  different  than  the  value  associated  with  the  mach  number  at  the 
initial  check  point,  requires  a  flight  mode  of  accelerate  or  decelerate  to 
resolve  the  difference. 

An  error  condition  arises  if  the  position  of  the  terminal  check  point  is  not 
compatible  with  the  heading  specified  at  the  initial  check  point. 

LAUNCH:  The  distinguishing  characteristics  of  a  LAUNCH  leg  are:  1)  it 
is  always  the  first  leg,  2)  the  air  base  or  carrier  aircraft  is  always  the 
initial  check  point,  3)  the  terminal  check  point  is  automatically  defined  by 
the  climb  requirement  for  the  leg,  and  4)  the  fuel  and  time  expended  include 
all  modes  from  startup  until  the  terminal  check  point  is  reached. 

In  order  to  define  a  specific  LAUNCH  leg  it  is  necessary  to  specify  the  fol¬ 
lowing  parameters: 

•  The  direction  of  LAUNCH.  This  may  be  specified  either  as  the 
direction  from  the  air  base  to  a  point,  or  as  a  beading. 

•  An  altitude  to  be  reached. 

All  LAUNCH  legs  automatically  compute  the  distance,  time,  and  fuel  nec¬ 
essary  to  move  the  aircraft  from  startup  to  the  point  at  which  the  specified 
altitude  is  achieved. 
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LOITER;  The  distinguishing  characteristics  of  LOITER  legs  are;  1)  an 
initial  and  terminal  check  point  which  are  geographically  coincident,  and 
2)  the  requirement  to  remain  in  the  vicinity  of  the  check  point  for  a  speci¬ 
fied  period  of  time. 

In  order  to  define  a  specific  LOITER  leg  it  is  necessary  to  specify  the  fol¬ 
lowing  parameters: 

•  Amount  of  time  in  LOITER, 
o  Mach  number  to  maintain. 

•  Altitude  to  maintain. 

A  LOITER  leg  is  made  up  of  a  sequence  of  climb,  accelerate/decelerate, 
turn,  and  cruise  flight  modes.  If  the  mach  number  and  altitude  do  not  re¬ 
quire  adjustment  with  respect  to  the  parameters  at  the  terminal  point  of 
the  previous  leg,  then  the  leg  is  a  series  of  cruise  modes  alternating  with 
ISO*  turn  modes.  The  length  of  the  cruise  legs  will  be  calculated  to  main¬ 
tain  the  aircraft  within  a  specified  distance  of  the  check  point  and  to  keep 
the  loiter  time  as  an  integral  multiple  of  the  time  around  the  "race  track". 
The  minimum  loiter  time  will  be  the  time  required  to  execute  a  360  degree 
turn. 

TERRAIN:  The  distinguishing  characteristics  of  TERRAIN  legs  are;  1)  a 
geographical  separation  of  initial  and  terminal  check  point,  2)  maintenance 
of  RPV  heading,  and  3)  the  requirement  to  maintain  a  specified  altitude  rela¬ 
tive  to  the  terrain. 

In  order  to  resolve  a  generic  leg  type  TERRAIN  into  a  specific  leg,  it  is  nec¬ 
essary  to  specify; 

•  The  relative  altitude  to  maintain. 

•  The  terminal  check  point. 

The  heading  and  Mach  number  at  the  initial  check  point  will  he  used  for  the 
terrain  leg.  The  leg  terminates  when  the  specified  distance  has  been 
traversed. 

DELIVERY  and  BOMB  DAMAGE  ASSESSMENT;  Although  defined  a  a  legs, 
one  distinguishing  characteristic  of  DELIVERY  and  BOMB  DAMAGE 
ASSESSMENT  is  that  they  are  each  in  fact  a  standardized  sequence  of  legs. 
The  sequence  of  legs  cannot  be  discretely  designated;  they  are  predesignated 
to  the  system.  A  second  characteristic  is  that  the  operator  is  semi- 
continuously  exercising  remote  control.  Finally,  the  termination  of  the 
sequence  is  triggered,  either  by  conditions  sensed  by  the  RPV,  (e.g, , 
weapon  release  or  by  an  operator  action,  or,  a  command  initiated  when  bomb 
damage  has  been  observed)  or  an  abort  command  if  the  target  is  not  attacked. 
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ESCAPE;  This  leg  type,  like  the  delivery  and  bomb  damage  assessment, 
is  in  reality  a  standardized  sequence  of  legs  that  contains  predesigned 
changes  in  flight  mode.  It  is  different  froqn  the  delivery  and  bomb  damage 
assessment  mode  in  that  remote  control  is  inhibited  and  termination  of  the 
activity  is  automatically  achieved  after  given  length  of  time. 

3. 3. 2,4  Command  Stacks  Organization 

The  form  of  a  stored  route/profile  is  a  table  of  commands  ordered  by  time 
of  execution  relative  to  mission  initiation.  It  is  called  a  Command  Stack. 
Each  entry  includes  the  execution  time,  the  command  type  (i.  e. ,  flight 
mode),  up  to  four  parameters  to  define  the  specific  command,  an  enable 
code  to  indicate  whether  or  not  the  particular  sequence  may  be  interrupted 
and  remote  control  accepted,  and  (whenever  remote  control  is  enabled)  a 
lock  code  (different  for  each  leg)  which  must  be  used  if  tne  RPV  is  to  ac  cept 
remote  control. 

Figure  3.  3-1  presents  a  portion  of  a  hypothetical  command  stack.  Line  1  is 
the  launch  command.  The  parameter  value  in  the  table  is  the  heading  in  de¬ 
grees,  Line  2  is  a  climb  command  to  be  initiated  30  seconds  after  launch. 
The  RPV  is  tc  climb  to  10,  000  feet  (100,  100  foot  increments).  The  RPV 
will  agjt  accept  remote  control  during  the  climb.  Line  3  is  a  turn  command. 
Since  it  occurs  at  300  seconds,  one  can  infer  that  the  climb  mode  was  com¬ 
puted  to  be  of  duration  270  seconds.  The  turn  is  to  be  executed  at  1.0  g's 
and  the  RPV  is  to  come  to  heading  305,  Notice  that  the  LAUNCH  leg  has 
been  converted  into  a  launch  mode  (line  2)  followed  by  a  climb  mode  (line  2). 
The  next  leg  (CRUISE)  is  made  up  of  a  turn  mode  followed  by  a  cruise  mode. 
This  occurs  because  the  final  terminus  of  the  cruise  leg  required  a  change 
in  the  direction  of  flight  (see  previous  CRUISE  leg  description). 

Lines  7  through  9  present  an  interesting  sequence  of  commands.  Line  7  is 
intended  to  represent  a  "pop  up"  to  5,  000  feet.  Line  8  is  a  command  to  ac¬ 
cept  remote  control:  if  remote  control  is  accepted,  when  control  is  returned 
to  the  RPV  itself,  the  route  will  continue  at  line  10  (parameter  2).  In  the 
event  that  control  is  not  accepted,  the  command  of  line  9  is  executed,  and 
remote  control  is  not  accepted.  If  communication  is  interrupted  during  the 
remote  control,  th"e~RPV  will  take  ita  next  command  from  line  16  of  the 
stack. 

Figure  3.  3-1  has  been  presented  in  English  for  ease  of  understanding.  In 
the  RPV  system,  the  data  would  he  in  numeric  coded  form.  Assuming  com¬ 
mand  times  can  he  expressed  in  seconds,  a  maximum  of  4  parameters  of 
2  bytes  each,  and  a  4  byte  enable -keyword  field,  each  command  in  the  stack 
will  require  15  bytes. 
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ID 

NUMBER 

TIME 

COMMAND 

VARIABLE  PARAMETERS 

ENABLE 

KEY* 

PI 

P2 

P3 

P4 

1 

0 

LAUNCH 

320 

.  . 

YES 

KEY  1 

2 

30 

CLIMB 

MIL 

100 

NO 

3 

300 

TURN 

306 

in 

NO 

4 

480 

CRUISE 

100 

NO 

6 

1880 

DESCEND 

220 

NO 

6 

I860 

TERRAIN 

400 

NO 

7 

6480 

CLIMB 

MAX 

YES 

KEY  2 

8 

6630 

REMOTE 

9 

10 

10 

YES 

KEYS 

9 

5800 

CRUISE 

100 

16 

NO 

•KEY  1  -  INITIATES  REMOTE  CONTROL  MODE. 

KEY  2  -  "LEVEL  OFF"  COMMAND  IS  INITIATEO  BY  RFV  ALTIMETER, 
KEY  a  -  REMOTE  CONTROL  BY  OPERAS  IS  ENABLED. 
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Figure  3.3-1,  A  Command  Stack  Example 

3.  3.2,  5  Command  Stack  Generation,  Program  and  Data  Base 

The  command  stack  is  generated  by  application  programs  as  the  planner 
generates  a  route /profile.  Each  leg  specified  by  an  operator  adds  com¬ 
mands  to  the  stack.  Commonly  occurring  sequences  of  legs  will  be  pre- 
coded  and  available  to  the  planner.  The  route/profile  generation  program 
is  to  be  built  in  a  manner  integrating  operator  specified  and  preplanned  legs 
automatically. 

Stack  occurrence  times  for  each  command  are  relative  to  mission  initiation 
time*  and  computed  by  processing  downward  in  the  stack  and  adjusting  tho 
variables  as  if  the  B.PV  was  traversing  the  route/profile. 

The  actual  process  of  command  stack  generation  can  proceed  only  after  the 
route/profile  has  been  specified.  The  command  stack  is  generated  by  pro¬ 
cessing  each  leg  of  the  route/profile  and  updating  an  RFV  state  vector  as  if 
the  RPV  was  actually  traversing  the  course.  Each  leg  is  converted  to  a  se¬ 
quence  of  flight  modes.  The  flight  mode  parameters  are  computed  taking 
into  account  such  factors  as  gross  weight  (which  is  a  function  of  fuel  con¬ 
sumption),  drag  index,  and  requested  leg  characteristics. 


$ 

Mission  initiation  time  may  itself  be  calculated  backward  from  time  over 
target  (TOT)  when  one  is  Specified  in  the  requirement.  If  no  TOT  is  pro¬ 
vided  an  initiation  time  or  TOT  muet  be  specified  by  the  planner. 


The  application  program  to  perform  the  command  stack  generation  can  be 
implemented  aa  a  control  program  supported  by  an  algorithm  processor 
and  a  data  base  retrieval  module.  The  actual  calculations  to  perform  can 
be  stored  in  the  data  base  and  expressed  in  terms  of  a  set  of  standard  func¬ 
tions  of  one  and  two  variables.  This  approach  has  been  investigated  on  the 
Mission  Planner  program  and  its  feasibility  has  been  demonstrated.  The 
main  advantages  of  the  approach  are: 

•  Logic  dependent  on  RPV  type  is  in  the  data  base. 

•  One  program  performs  all  computations. 

•  Changes  to  logic  and/or  introduction  of  new  leg  types  requires 
only  data  base  update,  not  program  modification. 

•  Fuel  calculation  and  performance  envelope  calculations  can  be 
included  in  command  stack  generation. 

The  logic  to  perform  computations  for  a  flight  mode  determines  the  space 
required  in  the  data  base.  Estimates  for  some  of  the  modes  are  presented 
in  Table  III,  3-4.  These  have  been  arrived  at  by  assuming  that  the  computa¬ 
tion  for  RPV's  will  not  differ  greatly  from  those  for  F4D/C  aircraft.  It 
should  be  emphasised  that  these  estimates  contain  storage  for  function  pa¬ 
rameters  as  well  as  boundary  value  checks  and  return  codes  for  error  indi¬ 
cations  and/or  performance  envelope  violation  checks. 

No  estimates  have  been  made  for  the  controller  or  the  data  retrieval  module; 
however,  the  algorithm  processor  requires  approximately  5280  bytes.0  This 
estimate  is  baaed  on  an  existing  processor  which  has  been  used  for  experi¬ 
mentation  with  data  for  the  F4D/C. 

The  storage  requirements  for  a  route /profile  are  a  function  of  the  number  of 
legs  and  the  data  required  by  the  route/profile  generator.  A  reasonable  esti¬ 
mate  is  between  12  and  16  bytes  per  leg.  To  this,  about  240  bytes  will  have 
to  be  added  for  a  name  and  any  restricted  uaage  or  interface  constraints. 

The  data  that  Have  been  presented  make  it  possible  to  estimate  the  total  data 
base  required  to  convert  a  preplanned  flight  profile  into  the  command  stack 
code  and  to  estimate  the  command  stack  storage  required  for  single  route 
profile  from  launch  to  recovery.  The  operational  assumptions  which  must  be 
made  are  the  number  of  mode  changes  per  leg,  the  number  of  legs  per  route 
profile,  and  the  number  of  standardized  preplanned  chains  of  legs.  Table 
HI,  3-5,  Quantitative  Factor*,  RPV  Route  Segments  and  Legs,  tabulates  the 


0 

This  represents  120  PL/1  statements  at  44  bytes  per  statement,  or  11  ma¬ 
chine  instructions  per  PL/ 1  statement  which  is  equal  to  1 . 3  KI. 
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assumptions.  Assuming  that  contingency  (e.g,,  emergency  RTB,  climb  if 
terrain  following  radar  fails)  are  common  to  many  and  that  there  are  a  total 
of  60  contingency  segments  in  the  system,  total  system  ADP  requirements 
can  be  summarized  as  follows: 


Program  Logic,  DCF 

Mode  Logic  Storage,  DCF 

Storage,  Single  Route  Profile,  RPV 

Storage,  20  mission  total.  Unit  DCF 

Storage,  80  mission  total,  Unit  DCF 

Storage,  240  mission  total,  Force  Planning  DCF 


1.3  KI's 
6,972  P/t'-s 
1 , 230  Bytes 
16,  500  Bytes 
61, 300  Bytes 
188, 100  Bytes 


Table  III,  3-4.  Storage  Requirements  for  Mode  Logic 


Flight  Mode 

Bytes  for  logic 

Accelerate 

!  "In  -  --- -  '  lllJUL  *,>m-  JB  u  -J  "H*7  -  1  •  rr-MTU-Mi  T1  li  rrr  J.r.  ■  "  -LJ~r‘  1 

1052  (two  throttle  settings*  MIL  and  MAX) 

Climb 

1052  (two  throttle  settings,  MIL  and  MAX) 

Cruise 

1920  (5  mach  numbers,  interpolation 
between) 

Descend 

576  (3  descent  modes) 

Launch 

250 

Recover 

32 

Terrain 

t 

1920  (5  mach  numbers,  interpolation 
between) 

Trigger 

32 

Turn 

60  (assumes  use  of  cruise  mode  as  a 
sublunction) 

Total  Mode  Logic  Storage  -  6974  Bytes 
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Table  III,  3-5.  Qualitative  Factors,  RPV  Route  Segments  and  Legs 


7 

Leg  / 

Legs  /Route 

Command  Stack  Storage 
Bytea/Route  Coded(U 

Launch  / 

/ 

1 

30 

Earoute  to  TOT 

15 

225 

Delivery 

3<2) 

135 

BBA  ' 

3«> 

135 

Escape  ■ 

f 

2(I) (2) 3 

90 

RT&  I  -  •  : 

.  /  ' 

10 

150 

l 

15 

1  &csfttiag®cy  fegmeists 

30(3> 

450 

Total  Storage/Route  Profile  Coded  1230  Bytes 


(I)  15  B^-tee  per  leg 

(Z)  e.g.,  Primary,  Secondary,  Alternate  Target 


(3)  Judgment  Factor 


3.3.3  Route  Planning 

3.  3.  3. 1  Constraints  and  Assumptions 

The  output  of  the  route  planning  function  is  the  input  to  the  flight  profile 
codiag  function  described  in  the  preceding  subsection.  The  requirement  for 
route  planning  is  to  establish  the  route  legs.  Standardized  legs  such  as 
LAUNCH  are  specified  by  designating  the  launch  site,  launch  corridor,  and 
the  altitude  to  be  achieved.  Other  legs  must  be  specified  in  terms  of  end 
points,  altitude (s)  and  mode(s)  of  flight.  This  is  not  unlike  route  planning 
for  manned  aircraft  systems.  However,  as  has  been  pointed  out,  there  are 
some  operational  considerations  that  are  relatively  RPV  unique  (e.  g.  low 
altitude  penetration). 

Currently,  route  planning  is  a  two  step  process,  One  step  relates  to  flight 
over  friendly  territory.  The  other  covers  flight  over  hostile  areas.  Routes 
over  friendly  territory  from  launch  to  an  ingress  point,  and  from  an  egress 
point  to  the  recovery  base  tend  to  be  constrained  by  factors  under  one's 
control.  Constraints  include  the  selection  of  ingress  and  egress  points  that 
are  compatible  with  routing  requirements  over  enemy  territory,  refueling 
requirement*  if  applicable,  and  TACS  control  requirements.  Restricted 
airspace  must  not  be  traversed.  A  significant  consideration  is  effective  use 
of  air  space,  all  airspace  requirements  considered.  These  constraints 
make  the  concept  of  using  a  few  preplanned  routes  over  end  over  very  de¬ 
sirable  in  one's  own  environment. 

Over  enemy  territory  the  primary  consideration  is  the  enemy  order  of 
battle;  i,  e. ,  the  location  and  capability  of  enemy  defenses  that  can  interfere 
with  successful  flight  to  and  from  the  target  area  and  target  defense  penetra¬ 
tion,  Other  considerations  include  range  factors,  visual  checkpoint  require¬ 
ments,  weather  factors,  etc.  Frequent  movement  of  enemy  weapons  and 
variability  of  target  locations  means  that  routes  to  and  from  the  target  must 
be  miscion  specific. 

The  general  considerations  for  RPV  route  planning  are  the  same  as  those 
for  manned  systems.  There  are,  however,  a  number  of  factors  that  signi¬ 
ficantly  impact  route  planning  for  RPV's, 

There  factors  ares 

a,  Navigation  position  accuracy:  The  degree  of  precision  required 
^epende  principally  on  the ' target  acquisition  requirements. 
Studies  of  these  requirements,  conducted  for  the  Air  Force, 
have  concluded  that  navigational  accuracies  in  the  order  cf 

390  to  1500  feet  are  required,  Given  these  limits,  accuracy 
has  little  impact  on  route  planning. 

b.  Low  altitude  penetrationi  The  RPV  is  designed  for  low  altitude 
penetration  to  "enhance  survivability.  Two  viable  options  are 
open.  The  one  option  includes  terrain  following  at  200  to  500 
feet.  The  other  option  is  pressure  altitude.  If  terrain 


clearance  is  maintained  by  flying  a  preplanned  pressure  altitude 
acceptable  flight  safety  altitude  will  probably  range  from  1000 
to  2000  feet  above  the  terrain  or  even  higher.  At  these  altitudes 
vulnerability  to  AAA,  especially  radar  controlled  AAA,  is  sig¬ 
nificantly  increased.  For  this  reason,  a  terrain  following 
capability  is  assumed  for  the  baseline  system.  The  effect  of 
having  a  pressure  altitude  capability  only  will  then  not  be 
assessed. 

c.  Line  of  sight  requirements:  Within  the  UHF  and  C  Band  fre¬ 
quences  that  may  be  used  to  communicate  with  the  RPV  terrain 
masking  between  the  RPV  and  the  relay  aircraft  can  signifi¬ 
cantly  degrade  or  prevent  communications.  Consequently, 
possible  enroute  and  over -the -target  terrain  masking  of  the 
communications  links  must  be  considered  in  route  planning. 

3.  3. 3. 2  Operational  Assumptions  Affecting  Route  Planning,  Low  Altitude 

Penetration 

Previous  studies  conducted  by  Rand,  Litton,  and  other  organizations  indi¬ 
cate  that  Almost  any  area  will  have  at  least  many  known  and  probable  AAA. 
sites.  While  AAA  and  any  SAMs  that  are  present  pose  a  threat  to  RPV, 
effective  route  planning  can  be  applied  to  noticeably  reduce  the  threat. 

Assuming  a  terrain  following  capability,  the  planning  requirement  tor  a  low 
altitude  penetration  to  the  target  i#  to  select  the  path  that  maximizes 
survivability  within  any  other  constraints  that  may  be  imposed  or  selected. 
(For  example,  one  may  wish  to  select  a  path  which  conceals  the  objective  of 
the  mission  at  is  not  likely  to  alert  target  defenses).  Since  defensive  .sites 
however  tend  to  have  small  lethality  areas,  and  tend  to  be  grouped  around 
targets,  it  la  quite  possible  to  circumnavigate  known  AAA  and  SAM  sites 
and  oilier  enroute  flight  hazards.  It  follows  that  the  effectiveness  of  AAA 
and  SAM,  and  the  amount  of  Intelligence  available  on  site  locations,  signi¬ 
ficantly  affects  the  required  capability  to  plan  a  defense  ivoidanee  flight 
path.  It  1-a  assumed  that  intelligence  data  are  available.  For  SAM  sites, 
it  is  assumed  that  SAM  sites  are  not  numerous  and  at  low  altitudes  can  be 
circumnavigated  (target  penetration  excepted).  For  AAA,  the  following  is 
assumed: 

a.  There  are  1 600  AAA  sites  within  an  area  200  nm  square. 
Assuming  an  average  lethality  range  of  2,  5  Km,  there  is 
a  28%  probability  that  the  RPV  enroute  is  in  a  lethality 
zone  if  a  defense  avoidance  route  is  not  planned. 

b.  These  1600  sites  are  at  the  more  than  2000  locations 
identified  as  AAA  sites  or  probable  sites. 

The  question  of  how  much  of  a  threat  AAA  is  for  a  low-flying  RPV  is  difficult 
to  answer.  Previous  studies  by  Litton  and  other  organizations  however,  do 
indicate  the  following: 
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a.  For  visual  detection  and  at  target  speeds  of  0. 85  Mach  in 

clear  weather,  there  is  approximately  a  50%  probability  of 
visual  detection  at  1700  meters  slant  range.  At  low  altitudes, 
this  appears  to  be  relatively  independent  of  the  specific  alti¬ 
tude.  The  threat  while  low  is  not  insignificant.  Statistically, 
given  1600  AAA.  sites  scattered  throughout  a  40,000  square 
mile  area,  approximately  30  lethality  zones  will  be  penetrated 
enroute  to  a  target  1 80  nm  from  the  FEBA  if  no  defense  avoid¬ 
ance  is  planned.  ! 

b.  For  radar  detection,  the  probable  low  altitude  detection  range 
exceeds  the  weapon  range,  so  any  penetrations  of  lethality 
zones  present  a  probability  of  loss  which  is  significant.  None- 
the  less,  very  low  flight,  200  to  500  feet,  introduces  terrain 
masking,  multipath  effects,  and  background  clutter  that  signi¬ 
ficantly  degrades  radar  controlled  AAA,  and  hence  increases 
probability  of  survival. 

If  the  RPV  does  not  have  the  radar  terrain  following  capability,  the  pressure 
altitude  level  for  the  flight  must  also  be  preplanned.  For  this  option,  the 
minim’un  safe  altitudes  are  in  the  range  of  1000  to  2000  feet  AGL  clearance; 
i.  e. ,  excluding  very  favorable  earth  surface  features  and  meteorological 
conditions.  This  higher  penetration  altitude  enhances  the  capability  of 
enemy  defenses  to  detect  track  and  acquire  the  RPV.  The  consequences  are 
that,  entoute,  it  is  even  more  important  to  select  a  path  that  avoids  defense 
lethality  zones. 

To  plan  a  defense  avoidance  path  wherein  coordinate  accuracies  are  in 
hundreds  of  feet  and,  on  the  average,  in  excess  of  70  points  (from  a  popula¬ 
tion  exceeding  2000}  and  which  must  be  avoided  by  pre -designated  distances, 
it  does  not  appear  possible,  using  manual  procedures,  to  still  meet  required 
response  times  for  planning.  The  next  subsection  addresses  the  subject  of 
automated  support  to  route  planning  for  defense  avoidance.  Before  turning 
to  this  process,  however,  the  requirement  for  and  desirability  of  incorporat¬ 
ing  terrain  masking  in  route  selection  is  addressed. 

The  importance  of  terrain  masking  to  avoid  long  range  early  warning  radars 
is  obvious.  Any  low  altitude  penetration  that  avoids  early  warning  radars 
by  10  or  20  miles  will  be  masked.  The  more  specific  consideration  is 
terrain  masking  of  radar  controlled  AAA.  Assuming  a  radar  detection  range 
of  10  to  20  miles,  a  zero  degree  masking  angle,  the  effective  AAA  lethality 
range  (under  3  Km},  and  AAA  response  time  (6  to  8  seconds),  it  is  necessary 
for  vehicles  flying  at  200-500  feet  above  terrain  to  be  masked  to  within  a  few 
miles  of  the  site  in  order  for  diem  to  obtain  a  significant  operational  advan¬ 
tage. 

There  are  however,  many  uncertainties  that  affect  the  value  of  such  masking 
consideration.  Exact  site  locations  are  not  known.  Detailed  dat\  would  also 
be  required  on  terrain  features  close  in  to  the  radar  site.  Although  favorable 
siting  can  be  assumed,  nevertheless  close-in  features  do  generate  masking 
angles.  Clutter  and  multipath  effects  are  possibly  as  significant  as  masking. 


3-57 


Quantitative  data  to  substantiate  a  conclusion  are  not  available.  Subjective 
considerations,  however,  have  lead  to  the  conclusion  that  uncertainty  of  die 
validity  of  the  results  of  calculated  terrain  masks,  plus  the  cost,  are  such 
that  terrain  masking  of  AAA  should  not  be  considered.  Therefore,  the 
proposed  implementation  procedures  for  defense  avoidance  planning  do  not 
incorporate  terrain  masking  for  AAA. 

3. 3, 3.  3  Route  Planning  for  Defense  Avoidance 

There  are  two  general  approaches  to  ADP  support  for  planning  a  defense 
avoidance  route  that  can  be  considered;  automatic  route  selection  (ARS)  and 
automatic  scoring  of  an  operator  selected  route.  For  automatic  route  se¬ 
lection  an  algorithm  that  can  select  the  lowest  cost  route  (minimum  threat 
in  this  case)  must  be  provided.  Generally,  to  find  a  best  route  many 
iterations  are  needed  to  find  a  solution  and  the  associated  processing  costs 
(and  response  times)  are  high.  Many  manageable  solutions  incorporating 
some  set  of  simplifying  assumptions  have  been  suggested;  some  have  been 
implemented.  The  second  approach,  automatic  scoring  of  an  operator 
selected  route,  requires  a  program  to  evaluate  the  threat  intersecting  a 
given  flight  profile. 

Since  route  scoring  is  subsumed  in  any  automatic  route  selection  process, 
route  scoring  is,  by  definition,  relatively  simple  as  against  automatic  route 
selection,  Provided  the  operator  can  select  a  number  of  good  routes  for 
trial,  the  route  scoring  approach  alone  is  quite  satisfactory. 

Automated  support  for  route  planning  has  been  studied  under  the  USAF 
Mission  Planner  program.  The  analysis  of  the  operational  requirements 
and  the  cost  and  effectiveness  of  alternative  implementation  methods  led 
to  the  conclusion  that  both  approaches  should  be  provided.  Automatic 
route  selection  is  applied  only  in  the  target  area.  By  limiting  the  si*e  of 
the  area  (SO  mile  radius)  and  hence  the  number  of  possible  routes  to  be 
scored,  satisfactory  response  times  are  realised.  Automatic  scoring  of 
an  operator  selected  route  is  applied  to  the  enroute  and  return  to  base 
segments  of  the  route  profile  where  the  operator  use#  his  light  pen  to 
select  a  route  that  avoids  heavy  enemy  defenses.  (He  usee  his  keyboard 
to  enter  altitude  and  velocity. )  An  automatically  generated  situation  display 
supports  this  selection  process.  The  route  safety  score  is  generated  for 
each  selected  route  at  an  accumulation  of  the  exposure  time  to  each  threat 
weighted  by  a  measure  of  threat  effectiveness.  By  trying  several  routes  a 
near  beet,  or  satisfactory,  route  can  be  selected. 

The  capability  provided  by  the  MPS,  as  described  later  in  Section  4,  is 
applicable  to  the  RPV  route  profile  planning  function.  It  provides  much  of 
the  capability  which  is  required.  There  are  however,  two  limiting  factors. 
The  automatic  route  selection  algorithm  severely  restricts  the  maneuvers 
permitted  within  die  high  threat  area  to  one  turn  no  tighter  than  120*.  The 
leaet  threat  route  selected  does  not  exploit  fully  the  capability  of  the  RPV 
to  perform  high  0  maneuvers  end  to  take  several  of  them  in  close  proximity 
to  each  other.  Increasing  the  tightness  of  turn  and/or  the  number  of  turns 
permitted  increases  the  number  of  paths  to  be  evaluated  and  thus  rapidly 
increases  response  time. 
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The  second  limiting  factor  relates  to  operator  time.  When  the  operator 
designates  the  position,  altitude,  and  flight  mode  for  each  leg  of  the  flight 
profile,  the  operator  time  obviously  increases  as  the  number  of  legs 
increase.  With  many  small  enroute  threats  to  be  avoided,  it  is  desirable  if 
not  necessary  to  plan  a  profile  with  many  maneuvers.  Under  these  circum¬ 
stances  operator  time  may  become  undesirably  high. 

3. 3. 3, 4  Automatic  Route  Adjustment 

This  section  addresses  a  proposed  approach  for  automatically  adjusting  a 
preselected  route  to  minimize  the  threat.  Applied  to  the  MFS  ARS,  it  is 
an  extension  to  the  ARS  capability,  Applied  to  operator  selected  routes,  it 
significantly  reduces  the  operator  time  required  to  select  and  define  the 
route  profile.  * 

Given  that  there  are  data  in  the  data  base  on  the  enemy  threats,  there  are  a 
number  of  procedures  that  can  be  automated  to  adjust  a  route  to  avoid 
threat  zones.  Logic  that  adjusts  a  straight  line  segment  intersecting  a 
threat  zone  can  create  a  sequence  of  shorter  length  segments  chained  by 
turns  such  that  threats  are  avoided  or  exposure  is  minimized.  Figure  3,3-2 
illustrates  the  situation.  The  route  segment  intersects  a  single  AAA 
lethality  zone.  Obviously,  by  moving  die  point  on  the  segment  that  is 
closest  to  the  AAA  site  away  from  the  site  to  a  position  that  is  outside  the 
threat  envelope,  the  threat  is  avoided.  For  single  threats,  the  logic  neces¬ 
sary  to  do  this  is  quite  simple.  For  multiple  threats,  the  logic  is  more 
complex,  but  conceptually  similar.  However,  if  discrete  logic  only  is 
applied,  the  route  path  circumnavigating  an  AAA  site  or  a  defense  complex 
would  always  reduce  to  a  predictable  pattern  which  the  enemy  would  soon 
recognize.  Hence,  it  is  desirable  to  introduce  a  random  factor  in  any 
automatic  route  adjustment  process. 
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Figure  3. 3-2.  Route  Segment  Threat 
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Assuming  an  automatic  route  adjustment  procedure  based  on  combining 
discrete  logic  and  a  random  factor,  the  following  is  required: 

a.  EOB  DATA  on  enemy  threats.  These  data  must  include  coding 
which  defines  the  direction  to  move  away  from  the  threat  site 
and  may  include  data  on  how  far  to  move  to  avoid  the  threat. 
The  data  can  be  defined  for  the  individual  site,  for  individual 
defense  complexes,  or  can  be  precoded  into  grids  covering  the 
total  enemy  area. 

b.  Program  logic  that  establishes  the  threats  to  a  route  segment, 
selects  a  point  on  the  segment  within  a  threat  area,  and  relo¬ 
cates  that  point  using  a  combination  of  discrete  logic  and 
random  selection.  The  route  defined  by  the  new  point  is  then 
evaluated.  Such  logic  may  be  iterated  until  a  no  threat  point 
is  found  or  until  trials  are  terminated  and  a  minimum  threat 
point  is  selected. 

c.  A  Program  logic  that  can  score  relative  threats  to  a  given 
route  and  select  the  least  threat  solution.  The  Route  Safety 
Scoring  process  as  implemented  in  the  Mission  Planner 
System  provides  the  basic  capability  required. 

The  data  processing  requirements  for  automatic  route  adjustment  are 
addressed  in  Section  4. 

The  process  is  initiated  by  the  operator  who  selects  a  route  which  is  grossly 
favorable  for  threat  avoidance  and  satisfies  other  operational  requirements 
and  constraints.  The  route  segments  can  be  relatively  long  and  he  need  not 
be  concerned  if  portions  of  the  path  penetrate  threat  rones.  He  does  attempt 
to  locate  leg  end  points,  however,  in  no-threat  areas.  The  operator  then 
selects  "automatic  route  adjustment"  and  designates  the  width  of  the  corri¬ 
dor  within  which  adjuetments  are  allowable.  This  is  s  variable.  The 
processor  then  locates  the  threats  which  interact  with  the  segment,  and 
•electa  a  point  within  the  segment  that  is  in  a  threat  area.  The  program 
logic  retrieves  tha  direction  to  move  and  calculates  the  minimum  distance 
(or  probable  minimum  distance)  to  move  to  avoid  the  threat.  This  is  based 
on  the  nominal  lethality  range  for  the  particular  threat  "B"  in  Figure  3.3-2. 
A  point  is  selected  for  trial  that;  1)  exceeds  the  minimum  distance,  and 
2)  is  less  than  the  corridor  width.  The  path  is  modified  to  go  through  this 
point  and  the  new  path  is  scored.  The  random  logic  determines  the  distance 
to  move  the  point  and  whether  movement  ie  from  the  site  to  avoid  the  threat, 
or  through  Che  site  to  the  other  aide  of  the  threat  ares.  The  process  is 
iterated  lot  each  threat  area.  An  original  itraigli  tin*  segment  fifty  miles 
long,  for  example,  may  be  converted  to  five  eegmemc  chi.in.ed  by  turns. 

The  no  threat  route  or  the  minimum  threat  route  found  will  be  displayed  for 
operator  approval. 

The  process  described  ie  suitable  for  a  high  defense  environment  to  select 
a  low  altitude  flight  path  which  circumnavigate •  most  er.rouie  threats.  The 
operational  advantage  of  automatic  route  adjustment  ss  described  is  two¬ 
fold,  First,  it  provides  a  capability  to  examine  many  route  variations 
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automatically  and  select  a  no-threat  or  least  threat  route.  The  second  ad¬ 
vantage  is  perhaps  more  important,  .For  an  RPV  flight  profile  with  a  pri¬ 
mary,  an  alternate  and  a  secondary  target,  plus  the  tactical  desirability  of 
avoiding  long  straight-line  segments,  it  is  estimated  that  about  fifty  legs  are 
required.  Considering  that  end  points  should  be  designated  with  an  accuracy 
of  several  hundreds  of  feet,  operator  time  to  define  each  leg  would  be  exces¬ 
sive.  The  automatic  route  adjustment  capability  makes  it  possible  to  plan  a 
profile  with  many  legs  with  relatively  little  operator  time,  since  he  must 
only  identify  the  underlying,  long,  straight-line  legs.  The  data  generated  by 
the  processor  are  in  a  form  that  can  be  automatically  converted  into  a  com¬ 
mand  stack  which  is  the  form  required  for  physical  control. 

3.3.4  Communications  Relay  Planning 

3.3.4. 1  Introduction 

The  route  planning  function  discussed  in  the  preceding  section  did  not 
address  the  requirement  to  maintain  line  of  sight  {LOS)  communications 
enroute  and  over -the -target  or  on-station.  The  planning  requirements  are 
complex  because  the  RPV  route  and  position  must  be  considered  concurrently 
with  the  position  of  the  relay  aircraft  at  each  point  in  time.  The  relay  air¬ 
craft  in  turn  at  any  time  may  have  to  communicate  with  as  many  as  20  RPV 
at  20  different  locations.  The  low  altitude  profile  of  the  RPV  and  the 
altitude  limitations  of  a  relay  aircraft  can  lead  to  significant  terrain 
masking  of  LOS  at  long  distances,  rhe  subsection  introduces  the  opera¬ 
tional  assumptions  that  impact  RPV  route  planning  and  communication 
relay  mission  planning.  The  assumptions  are; 

a.  Loss  of  communications  enroute  is  operationally  acceptable 
providing  the  "blackout  period"  is  short,  i.  e.  on  the  order  of 
a  few  minutes.  Even  longer  periods  may  be  acceptable  if  the 
blackout  has  bean  predicted  and  accepted  by  the  planner. 

b.  The  points  on  any  route  at  which  ehielding  will  materialize 
depend  upon  the  terrain  feature*  relative  to  the  location  of  the 
RPV  and  the  relay  aircraft. 

c.  One  communications  relay  aircraft  will  control  multiple  RPV 
vehicles  at  multiple  location*. 

Thee*  assumptions  introduce  complex  planning  problem*.  The  flight  path 
of  the  relay  aircraft  is  a  variable  and  the  altitude  of  the  relay  is  controllable 
within  limits.  The  path  and  altitude  of  the  RPV  are  also  controllable  within 
limit*.  The  beet  solution  cinnct  be  found  until  ail  RPV  mission  profile* 
have  been  developed  and  the  requirement*  for  communication*  established. 

The  earth* •  terrain  ie  the  only  constant  factor.  Automation  involving 
terrain,  however,  is  dependent  upon  digitised  terrain  data.  The  use  of 
digitised  terrain  data  introduces  problem*.  First,  digitised  terrain  data 
is  presently  not  available  for  many  potential  operational  areas.  Nonethe¬ 
less,  it  ie  assumed  that  in  tha  time  period  that  RPV  will  be  operational. 
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digitized  terrain  data  will  become  more  universal.  Where  digitized  terrain 
data  are  available,  the  storage  requirement  for  digitized  terrain  data  is 
great.  The  amount  of  processing  required  to  calculate  terrain  masking  data 
useful  for  RPV  route  planning  is  also  significant.  To  attempt  to  make  these 
calculations  on-line,  while  concurrently  generating  data  needed  for  commu¬ 
nications  relay  flight  profile  planning,  appears  to  be  unacceptable.  All  fac¬ 
tors  considered,  an  off-line  solution  to  establish  whether  communications 
links  are  shielded  appears  necessary  with  the  results  being  stored  for  on¬ 
line  planning. 

3. 3.4.2  Shadow  Effects  on  LOS  Enroute  Communications 

The  general  nature  of  the  terrain  masking  problem  can  be  appreciated  by 
visualizing  the  earth  shadows  that  can  be  seen  a  few  minutes  before  sundown 
since  at  a  relay  aircraft  RPV  range  of  180  nm  and  with  the  relay  aircraft  at 
60,000  feet,  the  shadow  angle  is  about  2°,  Figure  3.  3-3,  Schematic  Dia¬ 
gram  of  LOS  Shadow  Geometry,  illustrates  the  nature  of  the  problem. 

The  upper  portion  illustrates  the  vertical  profile  of  a  line  of  sight  shadow. 
The  scale  is  exaggerated.  With  the  geometry  assumed,  a  ridge  3000  feet 
above  the  surrounding  terrain,  the  relay  aircraft  at  45,000  feet  at  a  range 
of  160  nm  from  the  ridge,  the  length  of  the  shadow  is  22  nm.  Increasing  the 
altitude  of  the  relay  to  55,  000  feet  decreases  the  shadow  length  to  15  nm,  a 
decrease  of  approximately  0.7  nm  per  1000  feet. 

The  lower  portion  illustrates  the  plane  geometry  of  the  shadow  area.  The 
radial  of  the  shadow  edge  depends  on  the  position  of  the  relay  relative  to  the 
ridge  (the  length  of  the  shadow  area  depends  on  relay  altitude  as  described 
above).  Assuming  the  160  nm  offset  range,  as  above,  and  two  positions, 

Pi  and  Pj,  50  nm  apart  as  illustrated,  the  maximum  distance  between  'he 
edges  of  the  shadows  from  those  two  locations  is  7  nm.  A  shadow  area  cal¬ 
culated  for  a  position  midpoint  between  and  Pg,  could  apply  to  any  point 
between  Pj  and  Fg  with  a  maximum  shadow  edge  error  of  35  nm,  which  is 
approximately  20  seconds  of  flight  time. 

With  this  Introduction  the  approach  to  incorporating  communications  shadow 
in  RPV  route  planning  is  presented.  The  approach  presented  is  based 
k  f-*1  lowing  assumptions: 

a.  For  RVP's  in  the  enroute  and  RTB  legs,  loss  of  communication 
for  short  periods  is  operationally  acceptable. 

b.  Over -the -target  (after  pop-up)  continuous  communications 
are  required. 

c.  Shadow  effects  are  operationally  important  for  low  altitude 
penetration  only.  Penetrations  above  1,000  feet  will  be  at  an 
altitude  where  shadow  effect#  need  not  be  considered.  If  they 
must  fee  considered  because  of  some  exceptional  terrain 
features,  standardized  solutions  can  be  made  available. 
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d.  Altitude  errors  up  to  100  to  E00  feet  can  normally  be  expected 
in  the  digitized  terrain  data  used  to  calculate  shadows. 

e.  Accuracy  factors  are  such  that  terrain  shadows  calculated  for 
a  relay  aircraft  at  an  altitude  and  a  plane  coordinate  position 
can  be  applied  to  any  relay  aircraft  location  within  approxi¬ 
mately  25  nm  of  that  point,  and  within  5.  000  feet  of  die  altitude. 

f.  Any  shadow  depth  (vertical  distance  terrain  to  the  top  of  the 
shadow  plane)  less  than  flight  altitude  above  the  terrain  is 
considered  to  be  no  shadow.  The  RPV  altitudes  above  terrain 
considered  are  200  feet,  500  feet,  with  1 , 000  feet  optional. 

g.  A  shadow  area  smaller  than  about  10  nm,  longest  diagonal, 
about  10  seconds  maximum  shadow  time  is  ignored.  Within 
such  areas,  intermittent  shadowing  less  than  G.  5  is  considered 
no  shadowing,  shadowing  equal  to  or  greater  than  0.  5  is 
considered  shadowing. 

Considering  the  shadow  area  geometry  and  the  operational  assumptions, 
shadow  areas  for  a  given  operational  theatre  can  be  precalculated  and  be 
entered  into  die  data  base.  The  approach  assumes  that  the  most  likely 
flight  path  for  the  relay  is  basically  a  perimeter  around  the  enemy  area  which 
is  die  innermost  limit  of  the  "safe”  area.  This  perimeter  then  is  the  set 
of  positions  which  is  minimizing  the  distance  between  the  RPV  and  the  relay 
consistent  with  relay  safety.  Ihe  perimeter  or  potential  flight  path  Is  then 
divided  up  into  arbitrary  segments  approximately  50  nautical  miles  long. 
Segment  length  is  based  on  assumption  (e)  above.  The  midpoint  of  each 
segment  is  then  used  to  calculate  (off  line)  all  the  shadow  areas  which  result 
from  the  specific  terrain  features  inside  the  perimeter  for  each  of  three 
potential  relay  altitudes,  e,g.,  40,000;  50,000;  and  60,000  feet.  The 
location  and  configuration  for  each  shadow  zone  is  then  stored  to  be  used  in 
on-line  relay  planning. 

The  calculations  required  to  generate  the  shadow  area  data  using  digitized 
terrain  data  are  not  complete.  Since  the  calculations  will  be  made  off  line, 
the  processing  required  to  generate  these  data  are  not  included  in  the  RPV 
System  ADP  requirements.  Should  digitized  terrain  data  not  be  available 
for  an  operational  area,  shadow  areas  can  be  manually  generated,  with 
some  loss  in  accuracy  and  detail,  and  entered  into  the  data  base. 

3. 3. 4. 3  Application  of  LOS  Shadow  Area  Data  to  RPV  Route  Planning, 

Enroute  and  Return  to  Base . 

The  inputs  to  this  function  are  the  "shadow  areas"  generated  as  described  in 
the  preceding  subsection,  the  perimeter  flight  path,  and  a  RPV  trial  route 
profile.  Figure  3.3-4  illustrates  the  geometry  of  the  situation  and  depicts, 
schematically,  shadow  areas  as  they  might  exist.  The  situation  depicts  one 
RPV  route  profile.  Two  ridge  lines  that  will  shield  an  RPV  200  feet  above 
the  terrain  are  depicted-  For  each  ridge,  shadow  areas  are  depicted  for 
selected  segments  of  the  relay  flight  and  illustrated  for  a  50, 000  foot  relay 
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Figure  3.3-4  Schematic  Depiction  of  Shadow  Area* 

altitude-  The  reader  can  visualize  how  other  shadow  areas  for  other  zones 
and  for  other  relay  aircraft  altitudes  can  be  superimposed.  Many  more 
ridge  lines  producing  other  shadow®  can  be  envisioned.  Aa  illustrated, 
there  is  a  segment  of  the  flight  enroute  to  the  target  whore  the  relay  air¬ 
craft  mutt  be  in  zone  "H"  to  maintain  continuous  line  of  sight  communi¬ 
cations  .  An  alternate  route  that  makes  the  RPV  visible  to  other  relay  zone® 
is  depicted.  Over  most  of  the  route,  LOS  Communications  exists  to  all 
relay  aircraft  zones.  For  many  operational  areas,  this  is  a  likely  situation. 

In  subsection  3.3.3,  RPV  Route  Planning,  the  concept  of  route  safety  scor¬ 
ing  and  automatic  route  adjustment  to  minimise  threat  was  described.  The 
concept  for  incorporating  LOS  shadow  area  data  in  the  bata  base  is  the  same 
as  for  incorporating  threat  data.  Assume  50  ridge  lines  that  generate  opera¬ 
tionally  significant  shadow  areas,  (a  judgement  factor  to  develop  estimated 
data  base  requirements).  If  each  ridce  line  causes  shadows  in  four  of  the 
relay  flight  path  segments  and  two  R..  /  altitudes  and  two  relay  aircraft  are 
considered,  then  1.200  shadow  areas  must  be  coded.  At  32  bytes  per  area 
data  storage  required  is  38.4  K  bytes.  The  data  baoe  requirements  are  not 
unreasonable . 

I 

The  concept  for  use  of  these  data  when  planning  an  RPV  route  profile  is  as 
follows .  The  RPV  route  is  examined  automatically  to  determine  whether 
the  route  intersects  a  shadow  area  for  the  RPV  flight  altitude  planned . 

Those  segments  of  th#  relay  flight  that  produce  a  shadow  are  identified  and 
the  time  period  that  the  RPV  is  shadowed  is  maintained . 
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If  there  is  no  segment  that  will  provide  LOS  Communications ,  the  operator 
is  alerted.  He  may  accept  the  condition  or  select  to  modify  the  route.  The 
capability  to  automatically  adjust  a  route  profile  to  provide  LOS  communi¬ 
cations  is  incorporated  in  the  automatic  route  adjustment  algorithm.  AL- 
lowable  relay  aircraft  locations  which  provide  LOS  communications ,  (or 
alternatively,  locations  inhibited)  are  saved  and  are  used  in  the  planning  of 
the  communications  relay  mission  planning.  This  process  will  be  described 
in  subsection  3.3.4.  5. 

3. 3. 4. 4  Application  of  Terrain  Masking  to  RPV  on  Station  Planning 

The  approximate  solution  to  the  LOS  communications  problem  developed  in 
the  preceding  sections  is  suitable  for  the  enroute  phase.  Over-the-target, 
where  continuous  broad  band  communi cations  must  be  maintained,  a  more 
precise  method  for  evaluating  the  effects  of  terrain  mask  is  needed.  The 
nature  of  the  problem  is  essentially  the  same  as  in  terrain  masking  of 
ground  radar.  The  problem  to  be  resolved  is  whether  the  RPV,  at  its  al¬ 
titude  over  the  target,  is  masked  from  any  of  the  predesignated  relay  zones  . 
Conversely  one  must  determine  where  the  relay  aircraft  can  be  positioned 
to  provide  LOS  communications .  The  problem  is  solved  in  the  same  way 
that  the  radar  terrain  masking  problem  is  solved.  That  solution  is  to  cal¬ 
culate  the  masking  angles  for  targets.  Figure  3.3-5,  Masking  Angle  Geom¬ 
etry,  illustrates  the  geometry  of  the  problem. 

Given  the  masking  angle,  the  range  to  the  masking  terrain  from  the  target, 
the  range  to  the  relay  aircraft,  and  the  altitude  of  the  RPV  over  the  target, 
the  mimimum  relay  altitude  that  provides  LOS  communications  can  be  cal¬ 
culated.  Conversely,  given  a  maximum  relay  altitudefs),  the  minimum 
RPV  altitude  above  the  target  that  provides  LOS  communications  can  be 
calculated.  Additional  programming  is  required  to  apply  ground  radar 
terrain  masking  calculation  to  the  communi  cat  ions  relay  problem. 


Figure  3  3-5  Masking  Angle  Geometry 
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The  data  base  required  includes  masking  angles  for  each  target  at  20 
azimuths  and  the  range  from  the  target  to  the  masking  terrain  over  the 
azimuth  range  subtended  by  the  relay  aircraft  line  of  flight.  A  single  record 
is  about  four  bytes .  If  one  provides  in  the  the  processing  algorithm  a  logic 
that  interprets  the  absence  of  data  as  no  masking,  data  need  be  coded  only 
for  targets  that  are  actually  masked,  and  only  for  those  20  azimuths  which 
are  operationally  significant.  For  200  targets,  located  euch  that  a  46° 
sector  is  masked  for  each  target,  the  data  storage  requirements  are  16.8K 
bytes . 

These  data  are  used  to  establish  what  position(s)  along  the  relay  aircraft 
flight  line  provide  LOS  communications  over-the -target.  The  Planned 
Weapon  release  altitude  is  used  for  the  RPV.  If  LOS  communications  can¬ 
not  be  realized  for  any  relay  position,  or  if  the  target  is  at  an  extended 
range  and  a  closer  in  relay  position  is  desired,  the  calculation  can  gen¬ 
erate  the  RPV  pop-up  altitude  and  release  altitude  required  to  achieve  LOS 
communications  for  the  optimum  relay  position .  Alternatively,  it  can  cal¬ 
culate  a  position  to  which  the  relay  aircraft  must  move,  e.g.  50  miles 
closer  at  60,000  feet,  to  obtain  LOS  communications.  The  process  con¬ 
ceptualized  provides  considerable  flexibility.  The  program  requirements 
that  provide  this  capability  are  presented  in  subsection  3.3.5. 

3.3.5  Integrated  Communications  Relay  Flight  Profile  Planning 

3 . 3 . 5 . 1  Introduction 

The  data  generated  in  previous  subsections  defined  the  operational  require¬ 
ments  that  must  be  satisfied  by  the  relay  aircraft  mission  planner. 

a.  Over  the  target:  Relay  areas  and  associated  minimum  alti- 
tudes  tnat  provide  LOS  communications  to  each  target .  If  the 
relay  aircraft  must  be  positioned  off  the  predesignated  relay 
aircraft  line  of  flight  the  position  and  altitude  for  the  relay 
aircraft  are  developed. 

b.  Enroute:  For  each  RPV  route  profile  the  zones  within  which 
tile  relay  aircraft  can  be  positioned  to  provide  LOS  communi¬ 
cations  . 

The  communications  relay  planning  requirement  is  to  plan  a  relay  aircraft 
mission  profile  such  that  all  operational  requirements  will  be  satisfied. 

The  possibility  of  enemy  jamming  is  also  a  consideration.  (This  factor  is 
introduced  in  subsection  3. 3. 5. 3.)  First,  RPV  relay  mission  planning  re¬ 
quirements  for  communications  alone  are  considered.  Methods  for  incor¬ 
porating  jamming  considerations  are  then  addressed. 

Operational  assumptions  that  impact  the  planning  procedure  are; 

a,  There  is  more  than  one  type  of  relay  vehicle  in  the  inventory 
of  resources .  Each  vehicle  type  has  a  maximum  altitude 
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which  is  a  function  of  its  gross  weight.  (Fuel  load  is  tile  pri¬ 
mary  variable.)  The  mission  duration  is  a  £unct‘on  of  the 
vehicle  type  and  the  flight  profile  f^ect^d. 

b.  To  satisfy  the  operational  requirements  and/or  to  provide  ad¬ 
ditional  anti-jam  protection,  two  or  more  simultaneous  com¬ 
munications  relay  missions  may  be  planned.  The  implemen¬ 
tation  procedure  that  will  be  described  provider  for  simul¬ 
taneous  planning  of  two  simultaneous  relay  missions.  If  more 
missions  are  required,  additional  missions  can  be  planned  in 
turn. 


The  planning  procedure  is  a  two-step  process .  The  first  step  is  to  plan  a 
relay  mission,  or  a  set  of  missions,  that  satisfy  the  operational  require¬ 
ments  developed  by  the  route  planning  function.  The  second  step  in  the  plan¬ 
ning  process  is  to  incorporate  factors  that  will  minimize  the  effect  of  possi¬ 
ble  enemy  jamming . 

3.3. 5.2  Communications  Ruiay  Mission  Flight  Profile  Planning 

The  requirement  to  plan  the  relay  aircraft  mission  is  to  locate  the  relay 
aircraft  along  its  line  of  flight  such  that  at  any  point  in  time  its  location 
satisfies  the  enroute  and  GTT  communication  requirements.  An  obvious 
constraint  is  that  it  takes  time  to  reposition  the  relay  aircraft.  Considering 
that  the  communications  requirement  for  each  RPV  changes  with  time  (posi¬ 
tion  and  phase)  and  that  up  to  20  requiremer  »s  must  be  satisfied  simultane¬ 
ously,  the  problem  is  one  of  continuous  matching  of  capability  to  require¬ 
ments  .  To  make  the  problem  more  manageable,  a  process  that  yields  suc¬ 
cessive  solutions  for  discrete  time  intervals  is  proposed-  For  purposes  of 
analysis  of  the  processing  requirements,  a  5  minute  time  interval  is  as¬ 
sumed.  This  time  interval  is  small  enough  so  that  mission  geometry  is  not 
significantly  changed,  and  large  enough  so  the  number  of  processing  iterations 
required  are  not  excessive.  (It  should  be  noted  that  the  use  of  5  minute  time 
intervals  does  not  prevent  a  discrete  assessment  of  requirements  for  LOS 
communications  over -the -target  that  exist  for  shorter  periods,  e.g. ,  one 
minute . ) 

The  process  proposed  is  as  follows.  For  each  5  minute  interval,  starting 
at  a  time  selected  by  the  operator,  data  are  obtained  on  all  locations  that 
can  satisfy  the  communications  requirements  for  RPVs  airborne  during  that 
interval.  Those  locations  that  satisfy  all  requirements  are  "saved."  The 
next  time  period  is  then  examined  and  the  same  data  are  extracted.  If  re¬ 
lay  aircraft  locations  are  different  the  aircraft  is  repositioned  with  the  con¬ 
straint  that  the  aircraft  cannot  be  moved  a  distance  that  is  not  compatible 
with  its  air  speed  and  climb  rate.  The  process  is  interated  over  the  period 
of  the  relay  aircraft  mission.  In  this  manner,  a  relay  aircraft  flight  pro¬ 
file  and  schedule  can  be  generated . 

An  algorithm  yielding  a  good  solution  requires  many  checks,  enable  rules, 
and  operator  override* .  Without  flow  charts  and  very  detailed  text,  the 
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process  envision’”?  cannot  be  completely  described.  The  principal  features 
of  the  program  however,  are: 

a.  The  operator  can  designate  a  preferred  or  a  desired  location 
for  the  relay  aircraft  for  any  time  interval. 

k*  The  process  for  planning  a  relay  mission  need  not  start  with 
take  off  and  first  time  at  an  operating  location.  It  may  be 
initiated  at  a  point  and  time  where  requirements  are  demand¬ 
ing;  t.g. ,  where  maximum  altitude  is  required  and  very  little 
flexibility  in  terms  of  path  location  is  possible.  From  such  a 
start  point,  planning  can  proceed  back  in  time  and  forward 
from  take  off  to  landing  ■ 

c.  Rules  are  provided  to  automatically  select  preferred  locations 
for  any  time  interval. 

Rules  are  provided  that  through  the  iteration  process  allowable 
locations  are  reduced  to  a  set  of  preferred  locations  which 
finally  are  reduced  to  selected  locations  which  define  a  flight 
profile. 

e.  Orbiting  is  allowed  but  is  not  selected  as  a  preferred  tactic 
(unifies  so  designated  by  the  operator), 

f.  Two  relay  missions  maybe  planned  simultaneously.  Additional 
missions  that  may  be  required  to  provide  additional  capacity  or 
capability  and/or  backup  communications  may  be  planned  in 
turn.  (While  algorithms  can  be  conceived  that  would  pien  more 
than  two  missions  simultaneously ,  subjective  consideration  is 
that  processing  requirements  increase  very  rapidly  with  but 
little  operational  advantage  vis-a-vis  in  turn  planning). 

g.  If  two  simultaneous  relay  missions  are  planned,  there  is  an 
assignment  capability  which  assigns  an  RPV  mission  to  a  relay 
aircraft,  Handover  time  from  one  relay  to  the  other  are  pro¬ 
vided,  Unassigned  RPVe  are  accounted  for, 

h.  Over-the -target  communications  take  precedence  over  enroute 
control, 

i.  If  no  complete  solution  is  found,  the  best  solution  10  generated 

and  displayed  together  with  data  on  requirements  not  satisfied 
(E.G,  RPV  mission  #  .  masked  over  a  segment  of  the 

route  profile) 

j«  The  process  incorporates  anti -jam  considerations. 

The  program  required  to  provide  the  capability  described  has  been  consi¬ 
dered  at  a  level  of  dotail  below  what  ha*  been  documented .  The  program 
and  processing  required  to  implement  the  program,  documented  in  sub¬ 
section  3 . 3 . 5 . 3,  is  based  on  these  concepts  . 
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3.D.5.3  Communications  Relay  Planning,  Anti-jam  Protection 


3. 3. 5. 3.1  Operational  Factors.  There  are  unknoUm  data  that  significantly 
affect  *he  requirements  to  plan  for  anti- jam  protection.  Questions  that 
might  be  raised  are: 

c  What  is  the  enemy  capability  to  jam  critical  RPV  communi¬ 
cations  links  ? 

o  What  is  the  capability  within  the  communications  subsystem  to 
counter  jamming? 

o  How  many  jamming  sites  can  the  enemy  activate? 

To  provide  a  basis  for  planning  a  relay  mission  flight  profile  that  incorpo¬ 
rates  anti-jam  protection  considerations,  the  following  are  postulated: 

a.  Given  that  the  U.S.  has  a  significant  number  of  RPV  with  a 
•trike  capability  and  that  the  system  can  be  degraded  signi¬ 
ficantly  by  enemy  jammers ,  the  enemy  would  seek  to  jam  the 
RPVs.  It  is  reasonable  to  postulate  that  jammers  might  be 
deployed  in  numbers  comparable  to  the  number  of  radar  con¬ 
trolled  AAA,  e.g. ,  around  800  sites  in  a  sophisticated  envi¬ 
ronment  . 

b.  Tb"  enemy's  extensive  jamming  capability  would  be  used 
judiciously.  Jamming  widely  used  might  degrade  his  own  elec 
tronic  systems;  also,  it  costs  to  jam. 

c.  Fo.  an  active  jamming  station,  the  closer  the  jammer  ap¬ 
proaches  in-line  ^oometry;  (:elay  aircraft,  jammer,  and  RPV 
in  lin*'  in  that  order, )  the  more  effective  the  jammer 

d.  If  the  jammer  is  not  in  line  {within  a  few  beamwidths),  the 
closer  the  relay  aircraft  is  to  the  RPV  the  less  effective  the 
jammer  will  be.  This  results  from  the  narrow  beam  com¬ 
munication  techniques  envisioned. 

e .  Earing  mif  iion  execution  r  lar  reil  time  data  on  active  enemy 
jammers  can  be  made  available.  These  data  can  be  used  to 
predict  the  short  period  effectiveness  of  jamming. 

f  In  some  employment  environments  where  the  memy  capability 
to  jam  if  limited,  data  will  br  available  to  predict  with  reason 
able  assurance  the  probable  location  of  enemy  jammers  and 
their  performance  parameter- . 

3 . 3 •  5 •  3 . Z  Planning  Relay  Missions  for  an  Intense  Jamming  Environment, 
Given  an  ln'!enie"limittung  environment.  it  is  'reasonable  to  assume  tfiat ‘the 
cost  to  implement  an  algorithm  tha.  discretely  selects  a  "best"  relay 
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position(s)  is  too  high  for  the  possible  benefits .  This  is  due  to  the  number 
of  potential  jammers  that  must  be  considered.  The  alternative  is  to  select 
relay  positions  that,  within  operational  constraints,  minimize  communi¬ 
cations  distances  and  maximize  the  probability  that  active  or  known  jam¬ 
ming  sites  are  not  in  line  with  the  relay  aircraft /RPV  communications  path. 

Minimizing  distance  is  easily  implemented.  Subsection  3 . 3. 5.2  described 
the  procedure  for  selecting  route  profiles  and  route  schedules  that  could 
satisfy  the  communications  requirements  without  jamming .  To  minimize 
distance,  one  selects  that  position  that  minimizes  the  length  of  the  longest 
critical  communication  path. 

Providing  a  communications  path  that  minimizes  the  probability  of  the  relay/ 
jammer /RPV  being  in  line  can  be  provided  by  providing  simultaneous  relay 
positions  for  two  aircraft.  This  is  certainly  a  viable  solution  in  an  employ¬ 
ment  environment  where  intense  jamming  can  be  encountered.  Having  se¬ 
lected  a  location  for  the  relay  aircraft  that  minimized  the  length  of  the  long¬ 
est  critical  conununications  path,  a  second  location  is  selected  that,  within 
a  cone  (e.g.  30  to  60°),  j-  at  right  angles  to  the  primary  communication 
path  and  minimizes  range.  Figure  3.3-6  illustrates  the  geometry  of  an  em¬ 
ployment  environment  and  relay  assignments  that  such  an  algorithm  might 
have  generated.  As  illustrated,  over-the-target  control  of  the  strike  RPV' s 
is  assigned  to  the  closer  relay  aircraft.  The  alternate  control  link  is  rough¬ 
ly  normal  to  the  primary  line.  Enroute,  the  control  is  by  the  closer  relay 
with  the  exception  illustrated.  Terrain  masking  generates  such  exceptions  . 

3.3.53.3  Planning /Replanning  Relay  Mission  in  a  Predictable  Jamming 
EnvironmehF^^ew^malii^  DTe^R^m^r^t^r<»s  w^ere  We'jamming 
environment  can  be  predicted;  environments  that  introduce  relatively  few 
jamming  sites  .  In  the  execution  phase  it  can  be  predicted  that  jamming 
being  encountered  will  persist.  Thus,  predictions  of  probable  jamming  can 
be  made,  and  planning  can  be  initiated  to  minimize  the  effect  of  the  jamming. 
Technically  the  problem  is  identical  in  the  planning  and  in  the  execution 
phase.  The  only  real  difference  between  preplanning  and  replanning,  or 
adjustment,  is  that  for  replanning  time  factors  are  more  constraining. 

Given  the  requirement  to  communicate  with  an  RPV  in  a  specific  time  period 
(assume  an  RPV  over  the  target)  and  the  location  of  probable  jamming  sites, 
the  problem  is  to  select  a  relay  location  that  provides  LOS  communications 
and  maximises  the  signal  to  noise  ratio.  Signal  strength  is  a  function  of 
range  only.  The  strength  of  the  noise  signal  can  be  calculated  provided  the 
signal  characteristics  of  the  jammer  are  known.  With  these  data  it  is 
possible  to  calculate  the  S/N  ratio  for  several  relay  aircraft  locations  and 
find  which  location  provides  an  acceptable  or  a  most  acceptable  S/N  ratio . 
Note  that  an  acceptable  solution  may  necessitate  penetration  of  enemy  ter¬ 
ritory  and  expose  the  relay  to  an  enemy  threat.  From  a  data  processing 
point  of  view  the  problem  is  analogous  to  the  ECM  bum-through  calculation 
which  is  presently  implemented  on  the  Mission  Planning  System  breadboard 
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3.3.6  Over  the  Target  Planning,  Strike  Missions 
3 . 3 . 6 . 1  Weapon  Selection  Functions 

The  objective  of  the  weapon  system  assignment  function  is  to  select  that 
combination  of  ordnance ,  delivery  vehicles,  and  attack  tactics  that  is  most 
effective  in  achieving  the  mission  objective  with  the  most  acceptable  risk. 
These  three  selections  (ordnance,  delivery  vehicle,  delivery  tactics)  are 
interrelated  and  mutually  constraining.  The  best  selection  cannot  be  made 
unless  available  options  on  all  three  are  considered;  either  concurrently 
or  iteratively. 

In  planning,  the  initial  consideration  is  ordnance  selection.  Available  ord¬ 
nance  suitable  for  the  target  must  be  selected.  How  much  ordnance  of  a 
given  type  is  needed  is  a  function  of  the  target  type  (physical  features  and 
dimensions)  and  the  delivery  accuracy.  Delivery  accuracy,  in  turn,  is 
dominated  by  the  delivery  tactic  which  is  largely  established  or  constrained 
by  the  particular  delivery  vehicle  and  ordnance  selected-  The  final  deter¬ 
mination  of  how  many  aircraft  or  RPV's  are  needed  to  deliver  the  necessary 
quantity  of  ordnance  is  determined  by  the  delivery  vehicle  and  its  specific 
configuration  for  that  ordnance. 

The  threat  factor  is  a  principal  constraint.  Target  defenses  nu\v  be  such 
that  certain  combinations  of  delivery  vehicles  and  delivery  tactics  are  un¬ 
suitable  or  undesirable  and  may  be  excluded  by  the  Commander's  guidance- 
Where  options  are  available,  the  threat  must  be  assessed  before  the  most 
suitable  weapon  assignment  can  be  made.  Other  factors  such  as  weather; 
the  need  to  assign  multiple  strike  missions  on  the  target,  suitability  of 
ordnance  mixes,  and  the  constraints  of  resource  availability  umply  add  to 
the  complexity . 

Introduction  of  the  RPV  into  the  inventory  does  not  change  the  nature  of  the 
weapon  selection  problem.  For  manned  aircraft  systems  the  planning  load 
is  such  that  automated  support  to  the  weapon  selection  problem  is  necessi¬ 
tated  by  the  requirement  to  rapidly  assess  the  effectiveness  and  relative 
risks  of  availabls  alternatives .  The  same  decisions  apply  to  a  pure  RPV 
force  though  initially  RPV's  may  provide  fewer  options,  vie-a-via  manned 
systems ,  making  the  problem  somewhat  simpler . 

In  a  mixed  force  of  manned  aircraft  and  RPV's,  the  total  number  of  available 
options  that  must  bs  assessed  is  increased  over  pure  RPV  or  Manned  A/C 
forces.  Mors  important,  perhaps,  the  RPV  system  and  the  manned  system 
differ  in  respect  to  capability  to  achieve  a  mission  objective  and  acceptable 
risk,  Ths  conssqusncs  is  that  it  is  nscsssary  to  analyse  in  considerable 
detail  the  relative  effectiveness  and  survivability  factors  for  RPV's,  vis-a- 
vis  manned  systems  for  each  mission  prior  to  assignment.  Thus,  the  load 
is  heavier  for  a  mixed  force  then  for  a  pure  force  of  either  type.  The  con¬ 
clusion  is  that  automated  support  for  weapon  selection  is  a  firm  requirement. 


3-73 


3 . 3  •  6 . 2  Procedure*  end  AD P  Support  for  Wea  pon  Selection 

Weapon  selection,  as  used  in  this  report,  is  the  selection  of  ordnance,  the 
delivery  vehicle,  and  delivery  tactic  suitable  to  the  strike  mission  objec¬ 
tive.  It  is  assumed  that  ordnas.ce  effects  data  have  been  generated  by  intel¬ 
ligence.  Ordnance  effects  are  expressed  in  terms  of  delivery  accuracy 
CEP's.  Delivery  accuracy  in  turn  is  a  function  of  specific  carriers  and  de¬ 
livery  tactics . 

Under  the  Mission  Planner  System  program,  ADP  approaches  to  support  of 
the  weapon  selection  function  have  been  studied . 

The  process  implemented  in  the  MPSBB  for  automated  support  in  Weapons 
Selection  is  based  upon  the  Joint  Munitions  Effects  Manuals  (JMEMs). 

These  tables  are  organized  by  aircraft  type,  target  type,  and  ordnance  type. 
For  each  aircraft  type/target  type  pair  the  relevant  ordnances  are  listed 
along  with  delivery  tactics  and  fusing  data.  In  addition,  an  effectiveness 
measure  called  the  "single  pass  probability  of  destruction  (SSPD)"  is  pro¬ 
vided  .  This  value  is  based  upon  empirical  studies  and  is  used  by  the 
MPSBB. 

The  MPSBB  data  base  stores  the  three  ordnances  with  the  highest  SSPD  for 
each  aircraft  /target  type  pair.  When  a  target  type  and  an  aircraft  type  have 
been  selected,  the  three  ordnances  are  displayed  and  the  planner  selects 
the  ordnance  which  he  prefers.  Provision  is  made  for  selection  of  other 
ordnances  besides  those  displayed.  If  a  displayed  ordnance  is  selected,  the 
system  will  calculate  either  the  probability  of  success  for  a  given  number 
of  vehicles,  or  the  required  number  of  vehicles  for  a  given  (desired)  prob¬ 
ability  of  success . 

The  best  ordnance,  weapon  carrier,  and  tactic  may,  however,  b®  undesir¬ 
able  (or  unacceptable)  because  of  the  target  defenses  .  Consequently,  it  is 
important  to  assess  the  threat  to  a  mission  penetrating  target  defenses  and 
delivering  the  ordnance  particularly  as  it  affects  the  delivery  tactic  The 
route  safety  scoring  capability  described  in  subsection  3.3.3,  Route  Plan¬ 
ning,  is  applicable .  The  options  include  Automatic  Route  Selection  or 
Route  Safety  Scoring  of  a  designated  penetration  profile.  Use  of  such  threat 
analysis  in  the  weapon  selection  process  is  allocated  to  the  operator.  It  is 
especially  applicable  to  choices  between  RPV  and  manned  systems  in  a 
mixed  force.  Commanders  guidance  may  be  the  dominant  factor  in  the 
choice. 

ADP  Support  required  to  implement  the  weapon  selection  function  as  de¬ 
scribed  is  as  estimated  in  Section  5. 
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3.3.7  On- Station  Planning.  ECM 

3 . 3 . 7 . 1  Introduction 

The  objective  of  ECM  on-station  planning  is  to  evaluate  the  effectiveness 
of  available  ECM  techniques  in  suppressing  the  enemy  defense  capability, 
to  select  the  most  effective  ECM  against  the  threat  to  be  encountered  by 
planned  missions,  and  to  plan  the  tactics  that  will  maximise  the  effective¬ 
ness  of  the  ECM  support  selected. 

ECM  is  a  support  mission.  The  requirements  for  ECM  are  derived  from  an 
analysis  of  the  threat  to  planned  missions.  The  effectiveness  of  ECM 
missions  can  be  assessed  only  in  terms  of  the  degree  to  which  ECM  de¬ 
grades  the  capability  of  the  enemy  defenses  to  engage  friendly  missions. 
There  are  basically  two  ways  of  reducing  the  effectiveness  of  the  enemy 
defense  capability  through  the  application  of  ECM  techniques .  One  is 
directed  at  preventing  effective  engagement  by  suppressing  the  capability  of 
the  enemy  defense  system  to  detect  and  track  friendly  flights  and/or  prevent 
effective  control  of  weapon  intercept.  The  ECM  techniques  available  for 
this  application  include: 

o  Noise  jamming  of  early  warning,  detection  and  tracking  radars 
and  essential  communications  links. 

o  Various  types  of  decoy  jamming  and  "smart  jamming" 
techniques  to  induce  track  break  after  weapon  launch 

The  specific  mission  types  addressed  are  Noise  Jamming  and  Chaff  Pre¬ 
cursor  Mission. 

Another  way  of  using  ECM  to  degrade  enemy  defenses  is  to  induce  the  enemy 
to  expand  their  defensive  capability  against  false  targets  and  non-existent 
tracks  and  threats.  To  accomplish  this,  various  diversionary  and  decoy 
tactics  and  techniques  can  be  applied,  etg,  expendable  drones  that  generate 
tracks  appearing  to  be  manned  aircraft  flights.  The  effectiveness  of  such 
tactics  and  technique  are  highly  dependent  upon  the  campaign  strategy  and 
tactics  employed.  The  capability  to  plan  such  a  mission,  once  the  mission 
objective  is  established,  is  not  substantially  different  from  the  direct  support 
missions  that  are  addressed, 

3. 3 . 7.2  ECM  Noise  Jamming,  Mission  Planning 

Standoff  Jamming,  Escort,  and  On-Board  Jamming  are  similar  in  that 
these  missions  suppress  the  enemy  electronics  systems  by  introducing 
noise  into  the  victim  receiver.  To  be  effective,  the  noise  in  the  victim  re¬ 
ceiver  must  exceed  the  signal  being  protected  by  a  predetermined  threshold 

The  variables  in  calculating  jamming  effectiveness  as  defined  above  can  be 
quantified  and  the  relationships  among  the  variables  are  known.  To  calcu¬ 
late  the  strength  of  the  signal  to  be  protected,  the  following  variables  are 
input: 
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o  Geographic  location,  power  output,  and  the  signal  character¬ 
istic*  of  the  victim  radar. 

o  Range  to  the  mission  aircraft  that  are  to  be  protected,  a 
function  of  flight  profile . 

o  Radar  cross  section  of  die  mission  aircraft  which  is  a  function 
of  the  type  aircraft  and  their  configuration,  aircraft  formation 
and  the  aspect  angle . 

Given  these  inputs,  the  strength  of  the  signal  to  be  protected  can  be  calcu¬ 
lated  along  a  given  flight  profile . 

To  calculate  the  signal  strength  of  the  jamming  signal,  the  following  vari¬ 
able  are  inputs: 

o  Jamming  signal  strength  and  jamming  signal  characteristics 
which  must  be  matched  to  the  victim  radar  receiver  charac¬ 
teristics  . 

o  Distance  from  jamming  signal  source  to  victim  radar. 

Given  these  inputs,  the  strength  of  the  noise  signal  in  the  victim  radar  re¬ 
ceiver  can  be  calculated. 

While  the  problem  can  be  quantified,  the  application  in  a  dynamic  environ¬ 
ment  is  not  simple.  The  mission  aircraft  are  continuously  moving  relative 
to  the  enemy  defenses .  The  noise  source  will  be  moving  in  an  orbit  or  in 
some  other  mission  flight  profile  (in  these  applications,  it  is  assumed  that 
the  noise  source  is  not  on  the  penetrating  aircraft  or  RPV  so  that  triangu- 
lation  and/or  home-on  jam  techniques  are  nullified).  The  noise  to  signal 
(J/S)  ratio  must  be  calculated  along  the  flight  path  of  the  mission  aircraft 
being  protected.  If  the  required  J/S  ratio  along  the  flight  path  of  the  mis¬ 
sion  being  protected  is  not  achieved,  complete  defense  suppression  is  not 
achieved.  Investigation  of  the  J/S  ratio  along  the  route  will  determine  when, 
where,  and  for  how  long,  the  mission  being  protected  is  exposed  to  the  de¬ 
fensive  radar  nets.  Options  available  to  achieve  more  effective  defense 
suppression  include  modifying  the  noise  source,  modifying  the  flight  profile 
of  the  jamming  mission,  and/or  modifying  the  flight  profile  of  the  mission 
being  protected.  Assuming,  however,  that  the  flight  profile  of  the  mission 
being  supported  was  initially  planned  to  minimize  exposure,  the  primary 
options  are  to  modify  the  flight  profile  of  the  jammer  or  to  add  more  noise 
sources . 

Manually,  this  is  a  time-consuming  process,  As  part  of  the  MPS  algorithm* 
have  been  developed  that  automatically  calculate  bum  through;  that  is ,  a 
J/S  ratio  that  exceeds  a  pre-established  threshold  value.  The  data  can  be 
presented  so  ths  effectiveness  of  alternative  plans  can  be  quantitatively 
compared.  The  process  of  calculating  effectiveness  and  presenting  date  to 
the  operator  on  the  effectiveness  of  alternative  ECM  plans  is  described  in 
Section  4.  The  process  is  applicable  to  the  planning  of  RPV  ECM  missions. 
A  DP  support  requirements  to  implement  such  ADP  support  to  RPV  mission 
planning  is  addressed  in  Section  5. 
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3.3.  7.3  On-Station  Planning,  Chaff  Precursor  Missions 

There  are  a  number  of  applications  of  chaff  to  defense  suppression  The 
chaff  precursor  mission  is  commonly  used  to  screen  multiple  flights  of 
friendly  aircraft  penetrating  on  a  route.  In  other  applications,  chaff  may 
be  used  to  break  track  or  to  add  clutter  to  the  victim  radar  when  aircraft 
penetrating  target  defenses  are  within  the  defense  lethality  zones.  These 
latter  applications  are  typically  on-board  techniques  used  reactively  when 
a  flight  penetrating  target  defenses  is  being  tracked. 

Since  the  chaff  precursor  mission  is  a  primary  defense  suppression  support 
mission,  on-station  planning  for  the  chaff  precursor  mission  is  addressed. 
However,  the  principles  described  can  also  be  extended  to  other  types  of 
chaff  missions . 

In  planning  a  chaff  precursor  mission,  three  decisions  must  be  made: 

o  What  kind  of  chaff  bundles  to  drop. 

o  Where  and  when  to  drop  them. 

o  How  much  to  drop  {drop  interval) . 

The  initial  requirements  data  are  the  outputs  of  the  route  safety  scoring 
function  which  yields  data  on  the  exposures  to  be  screened  (see  subsection 
3.3.3).  Other  data  required  includes; 

o  Location  and  dimensions  of  the  screening  corridor,  and 
length,  width,  dept,  and  time  period  over  which  effective 
screening  must  be  provided. 

o  Radar  cross  sections  of  the  flights  to  be  screened. 

o  Technical  data  on  the  enemy  radars  to  be  countered. 

The  kind  of  chaff  to  drop  is  established  from  the  technical  data  on  the  victim' s 
radar(s),  specifically  the  radar  frequency  bands  to  be  covered.  It  is  ex¬ 
pected  that  this  will  be  accomplished  by  table  lookup.  The  second  decision, 
where  to  drop  the  chaff  bundles,  is  a  problem  of  determining  the  movement 
of  the  chaff  reflectors  as  a  function  of  time,  drop  rate,  dispersion  rate  and 
horizontal  displacement.  The  constant  factors  are  the  physical  character¬ 
istics  of  the  chaff  reflectors  and  the  dispensing  techniques;  the  variable  fac¬ 
tors  are  atmospheric  conditions,  horizontal  winds,  vertical  component  of 
winds,  turbulence,  and  atmospheric  density.  At  any  given  pressure  alti¬ 
tude,  the  principal  variable  is  horizontal  wind.  Given  the  dimensions  of  the 
chaff  corridor  required  and  the  movement  factors ,  the  drop  point  can  be  cal' 
culated  quite  simply.  There  are  two  constraints,  the  maximum  drop  alti¬ 
tude  feasible  and  the  optimum  time  between  drop  and  the  time  an  effective 
corridor  is  formed- 


The  final  decision,  how  much  to  drop  to  provide  continuous  screening,  is 
determined  from  the  dispersion  factors  described  above  and  the  technical 
data  on  the  chaff  reflectors. 

Consideration  of  the  type  of  decisions  required,  the  type  of  input  and  output 
data  required,  and  the  nature  of  the  processing,  leads  to  the  conclusion 
that  automated  support  to  planning  a  corridor  chaff  mission  can,  and  should, 
be  provided.  This  is  currently  under  study  in  ADMPS.  The  data  base  and 
data  processing  requirements  presented  are  based  on  an  implementation 
concept  that  applies  planning  factors  for  pod  selection,  still  air  drop  and 
dispersion  rates,  and  chaff  effectiveness  versus  time  after  drop  (chaff 
density  in  still  air).  Two  variables  are  introduced  by  the  operator;  horizon¬ 
tal  wind  components  and  an  atmospheric  dispersion  factor  related  to  the  air 
mass  stability.  With  these  inputs,  the  location  and  density  of  the  chaff  cloud 
versus  time  is  automatically  calculated  and  drop  intervals  are  established 
along  the  flight  path.  Requirements,  if  any,  for  parallel  drops  can  also  be 
calculated. 

The  algorithms  required  to  automatically  generate  a  chaff  precursor  mission 
flight  profile  and  to  establish  the  location  and  time  on  the  flight  profile  where 
the  chaff  is  to  be  dispensed  have  been  conceptualized.  Subsumed  is  a  capa¬ 
bility  to  select  the  chaff  pod  and  the  dispensing  technique  moat  suitable  for 
the  mission.  The  ADP  support  required  to  implement  the  process  is  ad¬ 
dressed  in  Section  5. 

3.3.8  Reconnaissance  Mission  Planning  Control  Considerations 

Analysis  of  the  requirements  to  plan  and  control  RPV  reconnaissance  mis¬ 
sions  was  not  required  for  this  study.  However,  need  for  an  RPV  Command 
and  Control  System  that  can  accomplish  reconnaissance  mission  planning 
and  control  has  been  considered  in  the  development  of  the  RPV  Command 
and  Control  system  concept. 

Relative  to  planning,  the  route  profile  planning  and  route  profile  coding  pro¬ 
cedures  which  have  been  described  are  applicable  to  reconnaissance 
missions. 

Reconnaissance  target  grouping  and  on  station  planning  for  RPV  reconnais¬ 
sance  is  similar  in  every  respect  to  manned  systems.  The  ADP  aupport  for 
reconnaissance  mission  planning,  currently  being  developed  under  the  ad¬ 
vanced  development  MPS  study,  is  applicable  to  RPV  with  only  minor 
modification. 

The  physical  control  of  reconnaissance  can  be  provided  by  the  launch, 
enroute,  return  to  base,  and  recovery  control  system  described  in  sub¬ 
section  3,2,  Physical  Control  of  RPV.  The  special  requirement  that  the 
reconnaissance  RPV  vehicle  introduces  in  the  need  for  the  ground  station  to 
receive  and  process  intelligence  data  obtained  in  real  time  or  near  real 
time.  This  requirement  is  not,  however,  RPV  unique  since  it  also  applies 
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to  manned  systems.  The  RPV  doe#  however  introduce  one  unique  factor. 
Since  the  RPVs  may  be  u*ed  to  obtain  intelligence  data  in  high  threat  envi¬ 
ronments  where  the  probability  of  loss  i*  relatively  high,  the  requirement 
to  provide  an  inflight  intelligence  reporting  capability  is  more  imperative. 

Implementation  of  real  time  and  near  real  time  transmission  and  processing 
of  intelligence  data  impacts  0 11  elements  of  the  RPV  system.  The  RPV  ve¬ 
hicle  must  be  instrumented  to  store  and  forward  intelligence  data  collected. 
The  communication  links  through  the  relay  aircraft  must  be  designed  to  pro¬ 
vide  the  communication  links  and  link  capacities  required.  The  ground 
based  element  must  be  capable  of  receiving,  processing,  and  distributing 
the  data.  The  ground  based  element  can  be  made  a  part  of  the  DCF  or, 
alternatively,  may  be  an  element  of  the  intelligence  processing  system  coiq- 
cated  and  interfaced  with  the  DCF  control  element. 

3.3.9  launch  and  Recovery  Control 

The  assumption  that  dominates  the  requirements  to  plan  launch  and  recovery 
operations  it  that  the  launch  and  recovery  operation  will  be  standardised, 
For  each  launch  and  recovery  site  there  will  be  preplanned  launch  and  re  ¬ 
covery  corridors .  Standard  emergency  procedures  will  be  preplanned. 

When  one  accepts  these  assumptions  (Air  Force  operations  personnel  who 
have  been  briefed  on  the  concept  have  accepted  them  as  valid)  the  require¬ 
ment  to  plan  launch  and  recovery  is  quite  simple.  The  following  require¬ 
ments  are  inherent; 

a*  For  an  operational  day  (or  other  operational  period)  select 
those  preplanned  launch  and  recovery  corridors  at  each 
launch  and  recover  site  that  may  be  used  (or  identify  those  not 
permitted).  Operational  factors  such  as  none*  restricted  for 
Army  use,  changes  in  friendly  order  of  battle,  and  RPV  launch 
and  recovery  corridors  reserved  for  training  may  cause  tem¬ 
porary  restrictions . 

b.  Within  an  operational  day,  the  factors  that  affect  the  selection 
of  acceptable  launch  and  recovery  corridors  are  resource 
availability,  weather,  and  the  schedule  requirements.  The 
considerations  are  simple.  Resource  availability  refers  to 
the  availability  of  launch  end  recovery  facilities  (RPV  avail¬ 
ability  was  verified  in  the  assignment  function) ,  The  principal 
weather  factor  is  wind  and  the  preferred  launch  corridor  wilt 
be  up  wind.  Threshold  factors  for  maximum  wind,  maximum 
cross  wind,  and  maximum  trj.il  wind  components  can  be  estab¬ 
lished  at  well  as  minimum  for  celling  and  visibility  The  lat¬ 
ter  apply  particularly  to  recovery.  Schedule  factors  relate  to 
the  maximum  launch  and  recovery  rate  at  any  launch  and  re¬ 
covery  sits 

The  simplicity  of  these  factors  leads  to  the  conclusion  that  there  is  no  re¬ 
quirement  to  provide  a  specific  algorithm  to  support  corridor  selection. 


Status  data  on  launch/ recovery  facilities,  and  weather  are  required  as  are 
data  on  RPV  operations  already  scheduled.  With  an  automated  system, 
these  data  are  in  the  data  base  and  can  he  automatically  displayed  on  request. 
It  is  well  within  the  capability  of  the  operator  to  manually  assess  status  and 
select  the  launch  and  recovery  site  and  corridor. 

An  algorithm  providing  automatic  schedule  checks  and  data  on  the  available 
launch  and  recovery  "time  slots"  that  are  equal  to,  less  than,  or  greater 
than  the  desired  launch  and  recovery  time  slot  would  be  a  useful  aid.  As 
will  be  addressed  later,  such  a  capability  is  required  for  monitoring  the 
operation.  A  schedule  cheeking  algorithm  is  required  to  examine  the  total 
schedule  for  possible  conflicts.  These  tame  ADP  capabilities  are  provided 
for  other  applications  and  should  be  applied  to  support  the  selection  of 
launch  and  recovery  site  and  time  ■ 

3.3,10  Plan  Review 

The  preceding  sections  have  addressed  discrete  planning  functions  with 
little  cons ide ration  given  to  the  requirement  to  insure  schedule  consistency 
between  individual  missions  and  for  the  force  It  might  be  asserted  that 
appropriate  coordinated  schedules  must  have  been  generated  since  individ¬ 
ual  schedules  are  controlled  by  the  time-over-target  or  time  on  station. 

Alao,  there  is  an  on-going  schedule  check  since  launch,  enroute,  and  re¬ 
covery  schedules  were  generated  to  be  consistent  with  the  controlling  time 
and,  at  the  same  time,  not  to  overload  communications  relay  missions, 
launch  and  recovery  sites*  or  other  mission-essential  facilities.  However, 
because  of  the  number  of  missions  planned  (up  to  240},  and  concurrent 
planning  by  multiple  operators,  undesirable  (or  unacceptable)  schedule  ad¬ 
justments  may  have  been  introduced  in  individual  missions  or  schedule  con¬ 
flicts  may  have  been  introduced  inadvertently.  A*  a  result,  there  is  a  firm 
requirement  to  review  ihe  total  operation  as  planned  to  establish  whether 
coordination  of  schedules  has  been  achieved ,  Further,  Current  Operations 
would  always  want  to  know  whether  adding  a  new  mission  to  the  schedule  or 
adjusting  a  mission  schedule  introduces  conflicts. 

Accepting  that  there  is  a  requirement  to  review  a  total  schedule  (Rani  for 
internal  consistency,  the  next  consideration  is  how  it  should  be  implemen¬ 
ted.  On  the  MPSBB,  there  is  a  capability  entitled  Time  Sequence  Review 
(TSR).  The  capability,  as  implemented,  provides  a  graphic  display  of  the 
location  of  all  airborne  missions  time -sequenced  through  a  specified  time 
period*  Simply  stated,  the  flight  plan  for  each  mission  is  used  to  generate 
synthetic  track  data,  which  is  displayed  with  update  rates  greater  than  real 
time.  Tho  operator  can  then  view  the  planned  movement  of  "missions" 
over  extended  time  periods  in  a  few  minutes  and  assess  the  time  and  apace 
relationships . 

In  addition,  the  TSR  capability  automatically  detects  airspace  conflicts,  both 
lateral  and  vertical.  The  constraint  is  that  an  airspace  volume  surrounding 
a  mission  is  not  permitted  to  intersect  an  airspace  volume  around  another 
mission.  This  capability  can  be  applied  to  RPV  mission  planning  to  insure 
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that  the  flight  profiles  and  schedules  do  not  introduce  airspace  conflicts. 

The  capability  can  be  applied  to  RPV  missions  only  or  to  all  missions  plan¬ 
ned  in  a  mixed  force  . 

The  requirement  to  provide  a  plan  review  capability  was  also  studied  under 
the  SEEK  FLEX  Study  and  for  the  Automated  TACC.  The  implementation 
concept  developed  for  those  studies  was  a  relatively  simple  check  in  real 
time  of  the  individual  mission  schedules  at  critical  points  along  the  route. 
Constraints  were  introduced;  e,g.  .  maximum  arrival  rates  allowable, 
maximum  sustained  arrival  rates  allowable  over  a  given  time  period,  or  no 
Bomb  Damage  Assessment  missions  on  a  target  within  a  time  period  less 
than  At  minutes  after  strike  or  greater  than  At  minutes  after  the  strike. 

This  limited  concept  can  provide  much  of  the  capability  required  to  auto¬ 
matically  review  a  force  plan  for  consistency  and  conflict. 

ADP  support  requirements  to  provide  a  plan  review  capability  are  addressed 
in  Section  5 . 

3.3.11  Mission  Monitoring  Functions 

3.3.11.1  Operational  Requirements  and  Assumptions 

There  are  two  aspects  to  the  mission  monitoring  function.  One  aspect  is 
the  monitoring  of  the  air  vehicle's  subsystem  performance  and  the  relation¬ 
ship  between  state  plarvad  and  state  achieved  (e.g. ,  time  of  arrival  at  a 
checkpoint).  The  outputs  of  such  monitoring  are  control  directives  neces¬ 
sary  to  achieve  the  esired  state.  In  manned  systems,  such  monitoring  is 
accomplished  by  the  pilot.  In  RPV  systems,  the  controller  exercises  phys¬ 
ical  control  (sulsection  3.2).  The  other  aspect  of  monitoring,  to  be  ad¬ 
dressed  in  this  subsection,  is  the  monitoring  of  the  progress  of  all  force 
missions.  The  operational  requirements  are  to  assess  the  state  of  mission 
essential  resources  and  the  progress  of  mission  execution  in  accordance 
with  the  plan.  Additionally,  the  effect  of  any  new  factors  (updated  intel¬ 
ligence  and  current  weather)  on  the  force  employment  plan  are  assessed,  as 
well  as  any  deviations  from  the  plan. 

The  introduction  of  RPV  into  the  inventory  does  not  significantly  impact  the 
force  monitoring  function.  The  operational  requirements  are  basically 
identical,  irrespective  of  whether  the  force  is  a  pure  manned  force,  a 
mixed  force,  or  a  pure  RPV  force.  Tht  -nly  differences  that  can  be  en¬ 
visioned  are  these: 

a.  Because  RPV  is  capable  of  maintaining  an  exact  preplanned 
profile  and  schedule,  there  are  increased  opportunities  to 
plan  clote  coordination  between  RPV  missions,  or  between 
RPV  missions  and  manned  missions.  More  exacting  coordina¬ 
tion  may,  however,  impose  requirements  for  more  exacting 
monitoring  to  sstav  ish  what  adjustments  are  required,  if  any, 
to  achieve  the  desired  coordination. 
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b.  The  fact  that  near-real-time  communication  between  the 

physical  controller  aid  the  force  control  element  is  operation¬ 
ally  feasible  introduces  additional  capabilities  to  exercise 
near -real -time  control,  This  may  require  the  maintenance 
of  current  status  in  more  detail  than  is  presently  required 
(e.g,,  more  frequent  position  reporting).  This  same  capa¬ 
bility  also  means  that  schedule  deviation  can  be  detected  and 
reported  automatically  (human  error  and  prejudice  eliminated). 
Therefore,  reporting  by  exception  may  be  more  acceptable 
tor  RPV's  vis -d- vis  manned  aircraft. 

These  difference*  are  not  differences  in  kind;  they  are  differences  in  degree 
only,  All  factor e  considered,  the  requirements  for  monitoring  RPV  vis-a- 
Viu  manned  aircnnft  are  basically  identical. 

3.  3,  II.  2  Implementation  Concepts  for  ASP  Support  to  Mission  Monitoring 

The  basic  premise  is  that  the  485 L  system  can  provide  the  monitoring  capa¬ 
bility  required  by  the  Ail*  Force  for  resource  status  monitoring. 

ADP  support  i-?,  however,  required  to  exercise  physical  control  of  the  RPV's, 
Once  ADP  in  established  independent  of  the  requirement  to  monitor  mission 
progress,  it  provides  a  capability  to  automatically  report  mission  status 
from  the  RPV  to  the  control  station.  In  turn,  the  capability  to  generate 
status  reports,  either  actual  status  or  exception  reports,  can  be  implemen¬ 
ted  with  little  additional  cost  in  terms  of  data  base  required  and  program 
and  processing  requiremonta ,  Were  this  desirable,  then  the  following  capa¬ 
bility  is  considered  as  required? 

a.  Automatic  generation  and  transmission  of  progress  reports,  in¬ 
cluding  launch,  strike,  on-station,  off-station,  recovery  and 
enroute  checkpoints . 

b.  Automatic  generation  and  transmission  of  exception  reports 
whenever  a  condition  exists  that  may,  or  will,  result  in  an 
operationally  significant  deviation  of  the  flight  profile  and 
schedule  from  that  planned. 

If  the  485L  data  source  terminal  (DST)  is  collocated  with  the  DCF,  or  is  an 
integral  part  of  the  DCF,  no  additional  ADP  support  is  required  to  provide 
this  capability  beyond  a  program  interfacing  the  physical  control  processor 
with  the  message  compost  ion  processing. 

In  addition  to  the  above,  the  plan  review  capability  described  in  subsection 
3,3,10,  Pi an  Review,  provides  an  automated  capability  to  review  planned 
operations  and  automatically  detect  facility  overloads  and  airspace  conflicts 
introduced  by  the  plan.  To  apply  this  capability  to  mission  monitoring  re¬ 
quires  only  mat  actual  times  be  substituted  for  planned  times  and  the  review 


program  be  executed.  The  concept  is  as  follows.  Schedule  exception  re¬ 
ports  are  automatically  initiated  whenever  a  deviation  exceeding  a  preset 
threshold  is  detected.  Such  reports  are  input  into  the  plan  review  function 
which  automatically  establishes  whether  the  deviation  generates  any  schedule 
conflicts  or  overloads.  If  it  does,  an  appropriate  alert  message  is  formu¬ 
lated  and  transmitted  as  follows : 

a.  The  message  is  displayed  to  the  operator  exercising  physical 
control  of  the  RPV.  This  message  also  includes  other  addres¬ 
ses  for  this  message  as  dictated  byS.O.P.'s, 

b.  The  physical  controller  takes  that  action  necessary  and  author¬ 
ised  to  resolve  the  conflict.  For  example,  if  an  RPV  is  re¬ 
turning  to  the  recovery  point  and  the  recovery  facility  is 
overloaded,  an  orbit  turn  or  hold  may  be  directed  by  the 
physical  controller  to  resolve  the  conflict. 

c.  Transmission  of  the  exception  report  to  other  addresses  is 
authorizec  by  the  operator. 

d.  If  the  schedule  deviation  is  transmitted  to  the  agency  exer¬ 
cising  force  control,  the  report' will  be  automatically  processed 
and  displayed  to  the  responsible  operator.  Within  the  TACC, 
this  will  be  a  function  of  the  485L  system.  No  additional  capa¬ 
bility  is  /required. 

e.  If  the  schedule  deviation  is  transmitted  to  the  CRC,  the  unit 
exercising  airspace  control,  the  report  will  be  processed  the 
same  as  any  other  schedule  deviation  report. 

In  general  the  ADP  capability  to  support  functions  involving  the  supply  of 
data  to  the  TACC  for  mixed  forces  is  sufficient  to  support  the  total  mission 
monitoring  function  for  a  pure  RPV  force  deployed  without  an  automated 
TACC. 

ADP  support  for  the  monitoring  function  is  addressed  in  Section  5. 

3.  3. 11.  3  Mission  Adjustment  and  Replanning  RPV  Missions 

The  mission  monitoring  function  provides  data  on  mission  deviations  and 
status  data  that  may  require  adjusting  the  operation  of  the  force  to  minimize 
the  effect  of  detected  deviations.  Additionally,  within  the  force  there  is  a 
capability  to  receive  and  assess  updated  intelligence  and  status  data  and 
immediate  requests  for  missions.  The  485L  system  provides  automated 
processing  and  display  of  such  reports  which  may  initiate  mission  replanning. 
It  is  assumed  that  the  485L  capability  is  available  at  the  TACC,  and  that 
there  is  a  DST  co -located  with  the  DCF  (or  that  the  capability  of  a  DST  is  an 
integral  part  of  the  DCF). 

This  subsection  addresses  the  requirement  to  plan  an  adjustment  to  an  RPV 
mission  and  to  cause  the  RPV  to  execute  the  adjustment.  Requirement  to 
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adjust  the  communications  relay  mission(s)  to  minimize  the  effect  of  jam¬ 
ming  is  addressed  in  the  next  subsection. 


The  functional  capability  required  to  replan  an  RPV  mission  is  basically 
identical  to  the  preplanning  function.  The  only  difference  is  that  for  re¬ 
planning  it  may  not  be  necessary  to  consider  every  segment  of  the  mission. 

Implementing  a  new  RPV  mission  or  adjusting  one  already  planned  intro¬ 
duces  a  unique  RPV  requirement,  the  necessity  to  code  the  changed  plan  and 
to  insert  the  plan  into  the  RPV  system.  If  the  RPV  has  not  yet  been  launched, 
the  process  is  identical  to  that  described  for  preplanning.  Response  time 
requirements  are,  however,  more  critical.  The  concept  for  current  opera¬ 
tions  makes  it  imperative  that  the  capability  be  provided  to  automatically 
convert  a  planned  profile  into  a  coded  flight  control  program.  (It  is  assumed 
that  the  response  requirement  for  RPV's  is  comparable  to  those  for  manned 
missions.)  If  an  airborne  divert  is  desired,  the  revised  program  must  be 
inserted  into  the  RPV  system  and  executed  while  the  RPV  is  in  flight.  The 
concept  for  physical  control  described  in  subsection  3.2  provides  this  capa¬ 
bility. 

The  conclusion  is  that  the  requirement  to  replan  RPV  missions  and  to  adjust 
preplanned  missions  and  to  execute  the  controls  to  implement  the  new  or 
modified  plan  can  be  satisfied  by  applying  the  capabilities  provided  for  pre¬ 
planning  and  for  physical  control.  As  before,  the  capability  is  sufficient  to 
perform  the  nocessary  replannig  or  adjustment  in  the  absence  of  any  part 
of  the  485L  system. 

3,  3, 11,4  Mission  Adjustment  and  Replanning  Communications  Relay 

There  are  any  number  of  conditions  that  can  initiate  a  requirement  to  replan 
relay  missions.  For  example,  relay  mission  delays,  aborts,  etc,,  can 
materialize.  One  critical  cause  for  'replanning  would  be  to  reduce  vulner¬ 
ability  to  enemy  ECM.  When  jamming  is  encountered,  the  location  of  the 
jamming  source  can,  in  many  situations,  be  established  as  a  strobe  line,  or 
a  location  which  is  an  intersection  of  two  or  more  strobe  lines.  From  an 
analysis  of  the  jamming  signal  received  and  the  intelligence  data  on  enemy 
jammers,  the  technical  characteristics  of  the  active  jammers  can  be  estab¬ 
lished,  With  ADP  support,  this  can  be  accomplished  in  near  real  time.  If 
one  simply  considers  the  geometry  of  the  problem,  a  relay  aircraft  at  a 
range  of  180  nm  from  a  jammer  flying  at  500  knots  normal  to  the  jammer 
line  of  sight  will  change  the  line  of  sight  "^>ff  angle"  at  a  rate  of  2.65°  per 
minute;  at  100  nm,  the  change  rate  is  4.9°  per  minute.  Assuming  reasonable 
directivity  of  the  communications  beam,  the  relay  aircraft  can  be  repositioned 
in  five  or  ten  minutes,  such  that  the  new  location  is  significantly  more  ef¬ 
fective, 

Enemy  tracking  of  the  relay  as  a  countermeasure  is  fully  effective  only  if 
the  Jammer  and  the  target  are  co-located.  The  enemy  problem  is  further 
compounded  if  there  are  two  relay  aircraft  on-station.  The  enemy  also  does 
not  know  ahead  of  time  the  target  objective  of  an  RPV  that  he  may  have 
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detected.  The  jammer  (s)  he  has  chosen  to  activate  may  not  be  the  most  ef¬ 
fective  against  an  attack  or  attacks  that  will  materialize  in  five  or  ten  min¬ 
utes. 

The  capability  required  is  to  assess  in  near  real  time  the  effect  of  a  pre¬ 
dictable  or  experienced  jamming  environment  on  the  relay  communications 
links  and  to  establish  how  the  relay  aircraft  might  be  repositioned  to  mini¬ 
mize  the  effect  of  jamming  being  encountered.  The  ADP  support  required 
to  provide  such  a  capability  has  been  described  in  subsection  3. 3. 5. 3. 3. 
Replanning  of  relay  missions  as  a  result  of  other  causes  is  well  within  the 
capability  of  the  planning  system  that  has  been  described. 

3.3.12  TAGS  Interfaces 

The  requirements  to  interface  the  RPV  Composite  Group  Command  and  Con¬ 
trol  System  with  the  TACS  is  similar  in  every  respect  to  the  interface  be¬ 
tween  a  maimed  aircraft  wing,  its  Tactical  Unit  Operations  Center  and  the 
other  TACS  elements .  The  TACC  inputs  the  frag  order  to  the  RPV  Group 
plus  directives  to  adjust  and  redirect  missions.  The  RPV  group  reports 
data  to  the  TACC  on  the  status  of  resources,  mission  schedules  developed  by 
the  RPV  planning  function,  and  progress  reports  of  missions  in  the  execution 
phase.  There  are,  however,  certain  unique  features  of  RPV  operations  and 
the  RPV  command  and  control  system  which  will,  or  may,  affect  the  quantity 
of  data  reported,  as  well  as  the  kind  of  data. 

These  considerations  are  largely  dominated  by  operational  factors.  It  is  not 
possible  to  resolve  them  from  an  analysis  of  the  RPV  System  alone.  They 
must  be  resolved  by  the  using  commands.  They  probably  cannot  be  resolved 
until  the  RPV  system  concepts  and  the  operational  concepts  for  employment 
are  clearly  specified,  A  general  conclusion  can,  however,  be  reached.  The 
opportunity  exists  for  greater  data  exchange  between  the  TACS  and  the  RPV 
force.  No  additional  functional  capability  is  required;  it  is  a  quantitative 
factor  only.  The  cost  to  provide  additional  capacity,  if  that  is  operationally 
desirable,  is  not  high,  It  is  a  factor  that  does  not  significantly  impact  the 
RPV  system  design  or  the  design  of  the  RPV  system  TACS  interface. 


SECTION  4 


MISSION  PLANNING  SYSTEM  APPLICATIONS  TO 
RPV  COMMAND  AND  CONTROL 


4.  1  INTRODUCTION  AND  BACKGROUND 

The  growth  of  aircraft  technology  and  the  requirements  arising  from  the  many 
problems  of  modern  tactical  air  operations  have  multiplied  the  amount  of 
information  that  must  be  considered  in  mission  planning.  Conversely,  these 
same  factors  have  decreased  the  time  available  to  do  so.  Automated  aids  are 
therefore  necessary  which  provide  the  planner  with  the  capability  of  rapidly 
reviewing  essential  elements  of  information  and  allowing  him  to  decide,  at 
each  critical  point  in  the  planning  process,  the  direction  in  which  he  wishes 
to  proceed.  The  critical  decisions  are  formulated  by  the  planner  through  his 
unique  ability  to  determine  patterns  and  trends  when  appropriately  presented 
with  a  large  number  of  factors. 

In  a  tactical  air  environment,  a  planner  is  almost  invariably  in  a  situation 
where  the  number  of  targets  which  must  be  attacked  far  exceeds  the  available 
resources.  Further,  operation  in  the  threat  environment  is  hazardous  to  the 
resources.  This  means  that  the  planner  must  face  four  major  responsibilities; 

a.  Insuring  that  each  mission  is  a  success. 

b.  Insuring  the  safe  return  of  his  resources. 

c.  Insuring  that  the  value  of  attacked  targets  is  high. 

d.  Insuring  that  his  resources  are  allocated  in  the  best  manner. 

As  mentioned  before  in  most  tactical  environments  these  responsibilities 
must  be  met  within  a  limited  time. 

Under  the  ground  data  processing  element  (691F)  of  the  Advanced  Develop¬ 
ment  Program  691,  "Force  Protection  Program",  the  USAF  Rome  Air  Devel¬ 
opment  Center  has  sponsored  the  development  of  a  Mission  Planner  System 
that  offers  the  capability  to  preplan  and/or  simulate  combat  and  combat  sup¬ 
port  missions  for  manned  aircraft.  The  system  includes  automatic  data 
processing  and  display  equipment  as  well  as  necessary  computer  programs  to; 
1)  rapidly  develop  and  evaluate  alternate  plans,  2)  through  an  iterative  proc¬ 
ess,  to  derive  an  effective  plan  for  a  given  mission,  and  3)  evaluate  the  over¬ 
all  effectiveness  of  this  planning. 

The  Mission  Planner  System  is  not  a  single  path  "canned"  process,  but 
rather  a  comprehensive  network  of  multiple  choices.  In  deciding  which  path 
to  take  at  any  given  mode  in  the  network,  the  planner  is  assisted  by  automated 
data  retrieval  and  presentation  techniques,  incorporating  comprehensive 
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effectiveneso /performance  criteria.  The  System  enhances  the  operator’s 
ability  to  perform  detailed  planning  of  associated  combat  and  support  mis¬ 
sions,  to  effectively  use  his  available  resources  to  satisfy  all  mission 
requirements,  and  to  maximize  the  probability  of  mission  success. 

The  Mission  Planner  program  achieved  a  significant  milestone  in  December, 
1971,  with  the  successful  development  of  a  comprehensive  group  of  computer 
programs  known  as  the  "breadboard  system. "  These  programs  have  been 
installed  for  test  and  evaluation,  on  a  commercial  data  processing  system  at 
the  Armament  Development  and  Test  Center,  Eglin  Air  Force  Base. 

The  Mission  Planner  Breadboard  can  be  applied,  almost  in  its  entirety,  to 
RPV  planning.  Subsection  4.2  discusses  in  detail  the  overlap  in  preplanning 
functions  for  manned  aircraft  and  RPVs. 

In  addition,  an  Advanced  Development  Mission  Planning  System  (ADMPS)  is 
being  developed  for  the  Air  Force.  This  ADMPS  will  have  expanded  capabil¬ 
ities  over  the  breadboard  system.  The  present  breadboard  system  handles 
only  strike  and  ECM  support  missions.  The  ADMPS,  however,  will  handle 
additional  missions,  such  as  reconnaissance  and  ELINT  missions. 

The  ADMPS  will  also  have  expanded  ECM  capabilities  in  areas  such  as  chaff 
and  other  expendables  which  have  direct  applicability  to  RPV  planning. 

In  considering  the  use  of  the  mission  planning  breadboard  for  manned  aircraft 
and  for  RPVs,  there  are  many  common  functions,  as  well  as  unique  functions, 
for  each.  Not  only  may  the  functions  be  different,  but  the  required  detail  and 
accuracy  of  the  plans  may  differ  for  manned  aircraft  and  RPVs,  There  are 
also  unique  functions  required  for  the  different  types  of  missions  such  as 
interdiction,  reconnaissance,  and  ECM  support.  The  following  subsections 
are  concerned  with  these  factors  as  applied  to  the  Mission  Planner  Breadboard 
System. 

The  first  subsction  (4,2)  describes  the  Mission  Planner  Breadboard  System 
and  illustrates  it  by  providing  a  single  thread  planning  scenario. 

Subsection  4, 3  describes  how  certain  of  the  breadboard  functions  have  already 
been  utilized  for  RPV  mission  planning  through  changes  in  the  data  base 
and/or  minor  program  modifications.  Breadboard  program  modifications 
necessary  for  extending  the  breadboard  system  to  accommodate  additional 
RPV  functions  of  Command  and  Control  are  found  in  4.4.  New  system 
capabilities  for  RPV  planning,  monitoring,  and  Command  and  Control  which 
could  be  added  to  the  breadboard  are  contained  in  Section  3,  In  Appendix  A 
there  is  a  description  of  the  demonstration  on  the  breadboard  of  some  of  the 
RPV  planning  functions  accomplished  for  interdiction,  Command  and  Control, 
and  ECM  support  missions  with  the  results  of  these  demonstrations. 
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MISSION  PLANNER  BREADBOARD  SYSTEM 


4.2 

4.2.1  Introduction 

The  Mission  Planning  Breadboard  System  consists  of  software  programs 
which  are  implemented  upon  a  commercial  computer  and  dual  displays,  as 
shown  in  Figure  4.2-1.  One  display  is  utilized  for  graphic  information  and 
the  second  for  alphanumeric  data.  The  Breadboard  System  is  capable  of 
demonstrating  the  automation  of  certain  functions  requisite  to  the  planning  of 
such  missions  as  interdiction  strikes  and  ECM  support.  The  System  provides 
the  planner  with  a  capability  to  deal  with  a  multiple  mission  planning  environ¬ 
ment  while  preserving  inter-mission  relationships  over  the  time  period  in  which 
which  the  missions  will  be  executed. 

The  Mission  Planning  Breadboard  System  augments  the  planner's  decision¬ 
making  process  from  the  selection  of  a  mission  requirement  through  the 


Figure  4.2-1.  Mission  Planning  Breadboard  System 
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completion  of  a  mission  plan.  The  operator  develops  a  final  plan  for  each 
mission  through  an  iterative  process  with  the  System  in  which  he  considers 
the  nature  of  the  target,  the  availability  of  resources,  an  optimum  route  to 
and  from  the  target,  the  characteristics  of  existing  threats,  and  all  available 
means  by  which  to  minimize  the  threats  in  executing  the  mission  assignments. 
After  each  mission  has  been  planned  the  System  supports  the  planner  in  his 
review  of  the  overall  multimission  plan  in  areas  of  coordination,  time  space 
conflict,  and  mutual  support.  The  planner  calls  for  various  planning  functions 
by  using  a  set  of  function  buttons  as  shown  to  the  left  of  the  graphic  display 
in  Figure  4.2-1. 

Some  of  the  planning  functions  which  are  presently  demonstrable  on  the 
Mission  Planning  Breadboard  System  at  Eglin  Air  Force  Base,  and  at 
Litton  Data  Systems  Division,  Van  Nuys,  are: 

a.  Target  characteristics  review. 

b.  Review  of  previous  missions  against  the  target. 

c.  Aircraft  and  ordnance  selection. 

d.  Resource  assignment. 

e.  Call  sign  assignment. 

f.  Enemy  Order  of  Battle  review. 

g.  Semi-automatic  route  selection, 

h«  Route  safety  analysis. 

i.  Automatic  route  selection. 

j«  Automatic  selection  of  on-board  jamming  equipment. 

k.  Automatic  configuring  of  aircraft  external  stores. 

1*  Fuel  calculation  and  tanker  requirements  development. 

m.  TAGS  assignment. 

n.  Automatic  selectiou  of  standoff  jamming  orbits. 

p.  ECM  effectiveness  analysis, 

q.  Time  sequence  review  (preflying  the  missions)  to  verify  mission 
compatibility  (no  time -space  conflicts)  and  continuity  of  planning. 
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The  Mission  Planning  Breadboard  System  was  developed  to  address  manned 
aircraft  missions  in  the  context  of  preflight  mission  planning.  The  current 
capability  has  recently  been  modified  to  include  some  unmanned  aircraft 
mission  planning.  Many  of  the  existing  planning  functions  can  be  used  in  con¬ 
junction  with  air  situation  data  in  a  logical  extension  of  the  system  to  include 
real  time  command  and  control  of  both  manned  and  unmanned  mission 
execution. 

4.2.2  Mission  Planner  Scenario 

The  following  pages  present  Mission  Planner  Breadboard  System  capabilities 
and  functions.  The  presentation  is  in  the  form  of  a  scenario  which  describes 
the  way  in  which  Mission  Planner  Breadboard  software  is  used  to  plan  inter¬ 
diction  missions,  as  well  as  the  ECM  support  for  those  missions.  Although 
the  Advanced  Development  Mission  Planner  will  plan  all  types  of  tactical  mis¬ 
sions,  the  present  Breadboard  is  limited  to  interdiction  missions  and 
ECM  support. 

The  scenario  is  set  in  North  Korea  and  assumes  that  three  things  have 
occurred  prior  to  the  start  of  planning. 

a.  A  set  of  requirements  (targets)  has  been  selected  and  given 
to  the  system  for  detailed  planning. 

b.  The  apportionment  of  sorties  for  interdiction  and  ECM  support 
has  been  accomplished. 

c.  The  data  base  has  been  updated  to  reflect  changes  in  friendly 
and  enemy  status. 

With  these  assumptions,  the  scenario  begins. 
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Upon  activation  of  the  function  key  INTERDICTION  PLANNING  the  set  of  requirements  for 
today's  planning  effort  appears.  Five  requirements  were  provided  in  the  scenario.  The  nature  of 
each  requirement  along  with  relevant  data  on  each  is  shown  on  the  alphanumeric  (A/N)  display. 
The  geographic  location  of  each  potential  target  along  with  the  location  of  friendly  bases  is 
shown  on  the  graphic  dtaptay. 

Aa  of  the  stert  of  the  scenario  resources  have  already  been  assigned  to  the  first  four  targets.  The 
scenario  describes  the  manner  in  which  the  mission  against  the  Hwang}u  POL  area  is  planned.  The 
process  begins  with  the  planner's  entering  via  the  keyboard,  the  mission  number  (710)  in  the  indi¬ 
cated  space  on  the  display. 


As  soon  85  «ny  targe t  is  safoetad  e  s$>aci«l  table  is  initiated  in  which  the  detail  of  the  pian  are 
stored,  this  table  is  called  the  Mission  Summary.  The  display  ties  its  own  function  button  „ 
and  the  planner  may  display  this  Mission  Summary  at  any  time  during  his  planning  cycle, 
Tito  table  consists  of  three  sections: 


2.  Plan  Data 

3.  Force  Data 

The  target  ctets  come  <$?eetiy  from  the  data  bass-  Thus  that  portion  of  tbs  labia  is  filled  in  as 
soon  as  the  target  is  selected.  The  other  two  sections  are  fitted  teas  the  planner  performs  the  vari¬ 
ous  planning  functions. 

When  the  planner  completes  &  Unction  either  tire  relevant  data  are  stored  directly  in  the  table  or, 
•If  she  data  are  voluminous*  art  m*rhk  te  .tsasf-to  indicate  completion.  Thus  it  can  serve  to  remind 
Him  Of  what  Still  needs  to  be  dona.  If  he  wishes  to  review  the  results  of  any  competed  function, 
ha  does  »  by  entering  the  appropriate  idenhMng  number  in  spaoe  at  the  bottom  of  the 
display. 
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When  the  planner  selects  a  particular  requirement  for  planning,  new  graphic  and  new  alpha¬ 
numeric  displays  are  generated.  The  A/N  display  presents  detailed  target  description  data  from 
the  data  fuse.  In  addition  to  the  basic  descriptive  data,  the  planner  gets  a  reference  to  a  target 
folder.  This  folder  contains  amplifying  hard  copy  data  on  the  target  including  any  reconnaissance 
photographs.  If  there  is  any  command  guidance  with  respect  to  this  target,  it  iu  included  in  the 
display  as  wall  as  a  reference  to  previous  strikes. 

The  graphic  display  continues  to  display  all  friendly  bases  but  the  upper  portion  is  modified  so 
that  only  the  selected  target  is  shown  las  an  asterisk!.  In  addition,  the  enemy  missile  and  AAA 
defenses  within  a  26  mile  radius  of  the  target  are  also  automatically  displayed. 

If  the  planner  wishes  to  review  the  previous  strike  against  this  target  he  does  so  by  entering  a 
symbol  in  the  space  in  the  bottom  line.  If  not,  he  activates  a  different  function  switch. 
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If  the  planner  selects  "Pre/post  Mission  Analysis"  the  displays  present  basic  data  on  the  previous 
mission  against  that  target.  The  graphic  display  presents  the  route  profile  as  it  was  planned.  In 
addition,  if  the  data  were  available  and  were  stored,  it  would  also  show  the  mission  as  it  was 
flown.  Any  EOB  (Enemy  Order  of  Battle)  reports  or  data  associated  with  the  mission  may  also  be 
displayed.  Discrepancies  between  the  "as  planned"  and  the  "as  flown"  routes  may  be  related  to 
events  as  described  in  pilot  debriefings  or  in  other  intelligence  sources. 

The  A/N  display  presents  amplifying  route  profile  data  and  after  reviewing  these  data  the  planner 
can  proceed  by  activating  another  function  switch. 
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The  planner  may  also  wish  to  review  command  guidance  prior  to  initiating  the  actual  planning 
process.  A  display  of  summarized  command  guidance  is  available  when  the  COMMAND  GUID¬ 
ANCE  function  switch  is  activated.  Command  Guidance  may  be  too  voluminous  or  complex 
to  be  shown  ]rj  toto  on  the  display;  therefore  the  displayed  Command  Guidance  may  consist  of 
references  to  appropriate  volumes  or  documents.  To  move  on  from  Command  Guidance  the 
planner  selects  a  different  function  switch. 
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The  first  scenario  action  for  the  planner  is  the  selection  of  ordnance.  This  function  is  initiated 
by  the  ORDNANCE  SELECTION  function  switch.  The  initial  A/N  display  requests  the  planner 
to  select  available  options  for  ordnance  selection. 

Ordnance  selection  is  accomplished  through  the  use  of  jMEMs  or  Joint  Munitions  Effects  Manu¬ 
als.  These  documents  are  the  result  of  combined  scientific  research  studies  as  to  the  effectiveness 
of  various  ordnance/aircreft  combinations  against  different  types  of  targets.  Abstracts  from  these 
documents  have  been  made  for  the  Mission  Planner  data  base.  For  each  possible  target  type  and 
aircraft  type  combination  the  three  best  ordnances  have  been  selected.  When  the  planner  selects 
a  specific  target  type  and  a  specific  aircraft  type  then  these  three  best  ordnances  are  displayed. 

In  the  display  the  planner  has  chosen  target  type  1  (Area  55  gal  POL  drums)  and  Aircraft  type  1 
(F-4D's).  The  planner  must  also  select  either  the  number  of  aircraft  he  wishes  to  use  in  the  attack 
$r  the  probability  of  successful  attack  that  he  wishes.  Whichever  value  he  enters  the  other  is  auto¬ 
matically  calculated  for  him.  In  the  present  case,  he  has  specified  a  60%  probability  of  success. 
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The  A/N  display  changes  to  present  the  abstract  from  the  JMEMs  for  F-4D  aircraft  against  55  gal 
POL  dr’ums.  Weapon  identifiers  and  other  data  have  been  altered  to  permit  this  document  to  be 
unclassified.  The  three  ordnances  which  are  (1)  certified  for  the  F-4D  and  (2)  best  for  this  target 
type  are  displayed.  In  addition,  fuze  data  and  optimum  tactic  are  included.  The  single  pass  proba 
bility  of  destruction  (Pq)  is  the  value  upon  which  the  calculations  are  based  and  is  also  displayed. 
Using  this  value,  the  computer  programs  have  determined  that  four  F-4D's  are  required  to  achieve 
a  probability  of  success  of  0.60  (or  over)  using  the  nine  -  M-224's.  If  the  planner  wishes  to  use 
the  nine  -  MK-95's,  then  five  aircraft  are  required  to  achieve  a  probability  of  success  higher 
than  0.60. 

The  planner  selects  the  nine  M-224's  by  entering  the  appropriate  digit  (i.e.  1)  in  the  space  labeled 
"Enter  Ordnance."  From  here  he  goes  to  the  next  target  type. 


4-19 


T8T  TYFf-  ONE  Nl  TANK  EM  0MMX7M  HIOH  (KIU), 


ORONANCE 

FUZE 

A/e 

NO. 

DIVE 

ALT 

KTAS 

FO 

FS 

1 

1 

urn 

411 

MU 

4 

• 

lit 

«M 

44 

17 

2 

(2 

MK-M 

111 

F40 

1 

3» 

m 

4*1 

.11 

a 

3 

« 

ILU-443 

INST 

F40 

I 

• 

IN 

4*4 

.11 

jj 

This  A/N  display  presents  the  JMEM  data  for  the  second  target  type  and  the  F-4D  aircraft.  For 
the  purpose  6f  the  scenario,  the  planner  selects  the  first  ordnance,  namely,  six  M-224's. 

After  he  has  selected  an  ordnance  against  each  target  type,  he  goes  to  Airbase  Resources  as  indh 
cated  In  the  display.  However,  prior  to  the  Airbase  displays,  a  short  digression  is  in  order  to 
show  what  happens  if  the  planner  wishes  to  use  another  ordnance  than  the  ones  shown  on  the 
JMEM  tables.  He  initiates  this  capability  by  selecting  "Ordnance  Menu." 
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The  planner  cen  override  the  JMEMs  and  select  any  ordnance  he  wishes  if  it  is  available  in  the 
theatre.  This  A/N  display  presents  one  page  of  the  Ordnance  Menu.  Each  ordnance  type  has  an 
identifying  number.  Using  the  next- to- last  line,  the  planner  selects  an  ordnance,  the  amount  to  be 
carried  by  each  aircraft,  and  the  number  of  aircraft  he  wishes  for  the  mission.  Notice  that  when 
the  Ordnance  Menu  is  used  the  breadboard  does  not  calculate  the  probability  of  success  nor  does 
it  determine  the  required  number  of  aircraft.  However,  the  data  are  stored  in  the  Mission  Sum¬ 
mary  and  ere  used  later  in  Configuration  and  Fuel  Analysis. 
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When  the  planner  selects  Airbase  Resources,  ha  receives  the  data  as  shown  in  the  A/N  display. 
Since  his  ordnance  selection  was  predicated  on  the  use  of  F-4D's,  he  must  select  either  Pusan  or 
Taegu.  He  selects  Taegu.  His  ordnance  selection  also  postulated  8  -  F-40's  aircraft  (four  against 
each  target  type).  Selection  of  Taegu  automatically  reduces  the  "A/C  Avail"  value  at  Taegu  from 
56  to4S. 

If  it  should  happen  that  the  ordnance  he  selected  earlier  was  not  available  at  Taegu,  he  would  be 
so  informed  by  a  message  at  the  bottom  of  the  graphic  display.  In  that  case,  the  planner  would 
presumably  select  "Ordnarce  Inventory.". 
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If  the  ordnance  were  available  at  the  selected  base,  the  graphic  and  A/N  displays  as  shown  here 
would  appear.  On  the  graphic  display  only  the  target  and  selected  airbase  are  displayed. 

The  A/N  display  is  modified  to  show  what  squadrons  are  at  the  selected  base  and  what  the  autho¬ 
rized  call  signs  are  for  each  squadron.  In  the  actual  display,  there  are  12  call  signs  provided  for 
each  squadron.  The  planner  selects  a  squadron  and  as  many  call  signs  as  he  requires  for  the  mission. 
Call  signs  are  assigned  by  groups  of  four  with  a  final  call  sign  being  assigned  to  any  left-over  air¬ 
craft.  For  example  if  5  aircraft  had  been  required  in  ordnance  selection,  he  would  assign  a  call 
sign  first  to  four  aircraft  and  then  assign  a  second  call  sign  to  the  single  remaining  aircraft.  If  he 
wished  to  send  eight  aircraft  rather  than  five  he  could  return  to  the  ordnance  selection  display 
and  specify  eight  aircraft. 

The  number  of  aircraft  per  squadron  are  automatically  decremented  and  the  bottom  line  keeps 
track  of  how  many  call  signs  remain  to  be  allocated  as  well  as  how  many  have  already  been 
assigned. 


If  the  planner  had  selected  Ordnance  Inventory  as  mentioned  earlier,  he  would  receive  this  A/N 
display.  It  represents  one  of  several  pages  describing  how  many  units  of  each  ordnance  type  are 
available  at  each  base.  The  planner  uses  these  data  either  to  select  a  different  ordnance  or  to  set 
up  a  requirement  to  fly  the  ordnance  from  a  base  where  it  is  available  to  the  base  where  it  is  not. 
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At  this  point,  the  planner  is  ready  to  start  route  planning.  This  function  is  initiated  through  the 
ROUTE  PLANNING  function  switch.  Because  the  breadboard  so  facilitates  planning  it  is 
assumed  that  there  will  be  times  when  the  system  is  not  being  used  to  plan  "tomorrow's  mis¬ 
sions."  Thus  it  can  be  used  to  "pre-plan  missions  against  targets  which  the  planner  is  sure  will 
become  requirements  in  the  future.  Such  missions  can  be  planned  and  stored  in  the  data 
base  until  that  target  does  become  a  requirement.  At  that  time,  the  mission  can  be  retrieved  and, 
if  it  is  still  satisfactory,  can  be  used  as  the  actual  plan.  Even  if  it  is  not  totally  satisfactory,  it  can 
be  the  basis  for  any  planning  which  must  be  done. 

There  are  three  factors  which  may  make  the  preplan  unsatisfactory.  These  are: 

1.  Changes  in  the  Enemy  Order  of  Battle  (EOB) 

2.  New  restricted  zones 

3.  Weather 

Activation  of  the  Route  Planning  function  automatically  displays  e  preplanned  route  to  the 
target  if  one  exists.  However,  in  addition  to  the  display  of  the  preplanned  route,  the  graphic  dis¬ 
play  also  contains  all  changes  in  EOB  data  which  have  occurred  since  the  date  of  the  preplan. 
Any  new  restricted  zones  are  also  displayed.  Thus  the  planner  can  immediately  evaluate  his  earlier 
route  in  terms  of  these  new  factors.  If  they  do  not  appear  as  cause  for  route  modification,  he 
can  accept  the  route  as  is. 

As  will  be  seen  later,  a  weather  display  may  also  be  superimposed. 

If  no  preplanned  route  exists  for  the  target,  the  last  historical  route  to  that  target  is  displayed  as 
the  basis  for  further  planning. 

In  the  present  scenario,  it  is  clear  that  the  preplanned  route  now  intersects  new  EOB  and  a 
restricted  zone  (P-30),  further  data  on  the  restricted  zone  are  available  by  lightpenning 
the  area. 

Route  profile  data  on  a  leg  by  leg  basis  are  presented  in  the  A/N  display. 
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ROUTE  PROFILE  MODIFICATION 
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Activation  of  the  "Route  Modification"  function  switch  results  in  the  alphanumeric  display  as 
shown.  The  planner  may  use  either  the  graphic  or  the  A/N  display  for  route  modification.  This 
display  is  used  to  indicate  the  node  or  point  at  which  the  planner  wishes  to  start  his  modification. 
He  may  identify  a  node  by  number  or  a  point  by  using  the  Hghtpen. 
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Selection  of  a  starting  point  automatically  causes  the  A/N  display  to  change  to  the  format  shown 
here.  This  format  Is  used  to  define  what  the  planner  wishes  to  do.  Selecting  one  of  the  three 
options  results  in  a  new  A/N  display  oriented  toward  making  the  desired  changes  except  in  the  case 
of  "Delete  Node."  If  "Delete  Node”  is  selected,  the  node  which  was  identified  in  the  previous  dis¬ 
play  is  deleted  and  the  route  automatically  is  connected  between  the  node  prior  to  and  subse¬ 
quent  to  ttie  node(s)  deleted. 

In  the  scenario,  the  planner  first  selects  option  3  -  Add  Cbeek-point(s). 
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Selection  of  Option  3  produces  this  alphanumeric  display.  The  display  allows  the  planner  to  use 
either  the  graphic  display  (llghtpen)  or  the  A/N  display  (node  number  or  Ut/tong  entry!  to  mod¬ 
ify  the  route. 

Using  the  lightpen  the  plainer  indicates  where  he  wants  the  next  node  to  be.  A  line  is  then  drawn 
by  the  processor  from  the  starting  node  (in  this  case  node  1)  to  the  indicated  point.  Subsequent 
lines  can  be  drawn  the  same  way. 

The  original  route  is  also  maintained  until  the  planner  causes  the  new  route  to  rejoin  the  old 
route.  At  that  time,  the  discarded  legs  vanish  from  the  scope  leaving  the  new  route.  Node  numbers 
are  automatically  changed  as  required. 

Notice  in  the  graphic  display,  how  a  new  node  2  was  created  which  by-passes  the  restricted  rone 
and  rejoins  the  old  route  at  node  3. 
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The  planner  may  also  desire  to  modify  other  types  of  data  relating  to  a  particular  leg.  Such  items 
are  leg  mode,  leg  altitude,  teg  Mach  number  and/or  thrust  setting.  To  do  so,  he  would  return  to 
display  shown  on  page  33  and  select  a  node.  For  the  example,  suppose  he  chose  node  3.  The 
next  display  would  be  the  one  previously  drown  on  page  37.  In  this  case  the  planner  would 
enter  a  "V'  (Modify  Checkpoint),  This  action  produces  an  alphanumeric  display  like  the 
present  one.  The  data  for  lag  3  as  they  presently  exist  are  included  in  the  format.  The  planner 
can  change  any  of  these  data  by  overwriting  his  desired  changes  in  the  appropriate  location. 
The  route  data  on  the  right  of  the  display  are  automatically  updated  as  are  the  data  in  the  flight 
plan  summary. 
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The  weather  display  is  generated  by  activating  the  WEATHER  function  switch.  This  display  is 
used  by  the  planner  to  determine  whether  his  old  route  or  his  new  one  should  be  modified  because 
of  weather.  Two  types  of  weather  data  are  presented  on  a  one  degree  by  one  degree  grid.  F  irst  the 
planner  is  shown  data  on  cloud  cover.  Cloud  cover  is  shown  where  it  exists  in  one,  two  or  three 
layers.  Layers  are  represented  by  the  letters  L,  M  and/or  H. 

L  *  low  level  cloud  cover 

M  «  medium  level  cloud  cover 

H  *  high  level  cioud  cover 

In  addition  areas  with  reported  turbulence  are  indicated  by  a  T. 

If  the  weather  appears  to  be  a  problem,  the  planner  can  refer  to  his  hard  copy  weather  data  and 
map  for  more  detail.  He  may  also  use  the  route  modification  capability  to  change  the  route  if 
necessary 
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By  selecting  the  EOB  REVIEW  function  switch,  the  planner  can  further  evaluate  his  route  on 
the  basis  of  enemy  order  of  battle  (EOB).  The  planner  selects  the  particular  threat  types  he 
i  the  menu  °f  the  a,(lhanurneric  display.  He  may  select  one  or  more  classes 

nUl9'  ,  ,I1AAAI  or  he  mav  ®,ect  one  or  more  subclasses  (e.g.  SA2,  SA3  and  57  MM  AAA) 
When  he  finishes  his  selection,  the  threat  elements  he  desires  are  displayed  on  the  graphic 
display  with  the  restriction  that  (1)  only  the  location  is  shown  as  indicated  by  a  letter  and  (2) 
only  those  threats  which  actually  intersect  his  track  are  shown.  (The  graphic  display  as  shown 
is  slightly  different  from  the  description  to  this  point  since  it  is  designed  to  show  many  capabil 


Referring  again  to  the  A/N  display,  if  the  planner  selects  "ALL”  he  is  shown  all  the  threats  of 
the  selected  classes)  in  the  tactical  area.  Selection  of  "COVERAGE.”  when  accompanied  by 
light  pen  action  at  a  site  location,  produces  the  circle  of  range  coverage  as  shown  in  the  graphic 
00  !*ETEf  when  accompanied  by  light  pen  action  removes  the  circles, 

t  n  us*d  With  a  class  selector  (e.g.  AAA)  removes  the  entire  class.  Durinq  any 
light  pen  actions  the  various  function  buttons  are  made  inoperative.  Selection  of  "Complete" 
after  light  pen  action  restores  the  option  to  choose  other  functions. 
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The  graphic  display  shows  a  typical  distribution  of  AAA  sites. 


IM  NSVStW  OWUV  KtECTtQH 


This  display  shows  a  possible  pattern  of  Missile  Control  Radars.  This  display  may  be  combined 
with  the  display  indicating  the  location  of  SAM  sites. 
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The  graphic  display  may  &so  be  used  to  display  the  location  and  coverage  of  fire  Control  Radari 
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In  order  to  request  a  display  of  enemy  Early  Warning  Radars,  6CI  sites  and  Airborne  Intercept 
capabilities,  a  second  menu  is  required.  This  format  is  used  in  the  same  way  the  previous  one 
was  used.  The  planner  selects  either  a  class  or  subclass  of  threat. 

The  graphic  display  shows  the  location  of  the  EW  radars  as  indicated  by  an  "E," 
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The  graphic  display  now  shows  the  capability  to  display  terrain  masked  coverage  of  a  radar.  This 
function  is  initiated  by  selection  of  "Terrain  Mask."  This  capability  is  actually  available  for 
Missile  Control  Radars,  Fire  Control  Radars  end  GCI  sites,  as  well  as  Early  Warning  Radars.  The 
coverage  age  of  an  EW  radar  (selected  by  light  pen  action)  at  the  altitude  flown  by  the  mission 
aircraft. 

While  the  programs  to  provide  this  coverage  ere  available,  the  actual  implementation  of  the  terrain 
masking  function  is  severely  limited  by  the  relative  unavailability  of  terrain  data. 
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This  display  is  typical  of  the  coverage  of  enemy  GCI  sites. 
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This  display  represents  a  typical  terrain  masked  display  for  a  GCI  site.  The  coverage  is  still  altitude 
dependent,  of  course. 
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This  is  the  display  which  the  planner  sees  when  he  requests  "Airborne  Intercept”  on  the  threat 
menu.  The  A/N  display  changes  to  include  data  on  the  number  and  type  of  enemy  aircraft  at  each 
base.  The  graphic  display  presents  the  location  of  enemy  airbases  with  the  airbase  identifiers. 
In  addition,  it  uses  the  letter  "C"  to  indicate  the  location  of  known  enemy  CAP  or  loiter  points. 


At  this  point  the  planner  has  tentatively  selected  a  route  as  shown  on  the  graphic  display.  He  may 
now  use  a  function  switch  to  request  that  the  selected  route  be  scored.  The  result  of  the  scoring  is 
shown  on  the  A/N  display.  There  is  a  score  for  the  whole  route  as  well  as  a  score  for  the  worst  leg. 
The  total  score  »n  each  case  is  composed  of  three  subscom. 

1)  0  score  or  Detection  score  which  is  a  measure  of  the  time  the  mission  is  within  coverage  of 
enemy  GCI  sites  and/or  £W  radars. 

2)  A.  Scot's  or  Acquisition  end  Tracking  score  which  is  a  measure  of  the  time  mission  aircraft 
are  within  coverage  of  missile  control  and/or  fire  control  radars. 

3)  l,  score  or  Lethality  score  which  is  a  measure  of  the  time  that  mission  aircraft  are  literally 
within  the  lethal  range  of  enemy  missiles  and/or  AAA.  The  l  score  is  further  subdivided 
into  Lm  and  LA  scores  which  denote  respectively  the  proportion  of  the  L  score  resulting 
from  nussilea  (L^)  and  AAA  {l^h 

Each  score  is  composed  of  two  factors.  First  there  is  a  time  factor  representing  actual  exposure. 
Secondly,  the  time  factor  is  multiplied  by  a  factor  which  represents  tba  effectiveness  of  the  par¬ 
ticular  threat  type,  Thus  the  scores  are  differentially  weighted  by  type. 

Further,  the  scores  are  also  altitude  dependent.  That  is,  even  though  an  aircraft  may  fly  directly 
over  an  AAA  site,  if  he  is  high  enough  to  be  out  of  range  his  score  is  zero  for  that  site.  In  addi 
tion,  since  the  coverage  range  of  various  radars  increases  with  altitude,  higher  altitude  flight  pro¬ 
files  will  gat  larger  0  and  A  scores.  Other  altitude  adjustments  are  also  included. 

The  score*  in  Route  Safety  Analysis  must  be  treated  as  relative  rather  than  absolute  scores.  They 
do  not  imply  that «  given  route  is  safe.  They  only  imply  that  one  route  is  safer  than  another.  Thus 
they  can  be  used  to  compare  alternate  routes. 
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I?  th$  fykppv&r  to  compare  the  scores  of  two  routes,  he  can  do  so  by  first  activating  a  func- 

r»<KS  button  which  is  labeled  "SAVE  ROUTE."  This  takes  the  first  route  (i.e.,  the  one  that  is  pre- 
sunwiy  on  the  scop©)  end  stores  i?  in  memory  with  its  score  pattern. 

At  this  8 cjsM..  the  planner  uses  the  "Route  Modification"  routine  in  order  to  develop  an  alternate 
^fosumaaly,  he  would  also  use  the  EO0  Review  capability  to  develop  an  alternate  whiJi 
hsd  some  probability  of  being  as  good  or  better  than  the  old  route.  Notice  that  by  starting  route 
modification  at  the  airbase,  the  planner  can  plan  a  totally  new  route  to  the  target  a*;  long  as  he  also 
ends  at  the  airbase.  He  treed  not  use  any  of  the  logs  of  his  earlier  or  "saved"  route. 

Once  the  alternate  route  is  defined,  the  planner  then  requests  that  this  route  be  scored  This  r« 
suits  in  the  alphanumeric  display  as  shown.  The  Scores  for  the  primary  or  saved  route  are  given  and 
a  parallel  set  of  scores  are  given  for  the  alternate  route.  H  the  planner  wishes  to  use  the  primary 
route,  he  activates  a  switch  labeled  "RESTORE  ROUTE"  and  all  data  on  the  alternate  route  are 
thrown  away.  If  he  wishes  to  choose  the  alternate  route,  he  activates  the  “SAVE  ROUTE"  switch 
and  the  earlier  route  data  are  replaced  by  the  alternate  route  data  which  now  define  the  ;.?»■ 
mary  route. 
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Although  tin  breadboard  system  does  not  provide  for  planning  support  missions  other  than  €CM, 
it  does  allow  the  planner  to  specify  the  kinds  of  support hcf eels  the  mission  requires.  Hisselec- 
ticn  of  support  may  be  a  function  of  the  relative  values  of  the  scores.  If  the  tA  score  is  high  he 
may  select  Flak  Suppression.  Conversely,  If  the  A  score  is  high,  the  answer  may  be  ECM  support 
of  some  kind.  (Stand-off  Jamming  or  Special  Support  Jamming) . 

Ha  may  also  recall  the  relevant  BOD  on  the  graphic  disp'ay  to  evaluate  the  actual  threat.  In  the 
present  scenario  he  decides  to  select  Fiak  Suppression  support  against  the  AAA  sites  shown  as 
dotted  circles. 


The  scoring  concept  as  described  earlier  is  used  as  the  basis  for  an  automatic  route  selection  rou 
tine.  At  the  present  time  automatic  route  selection  is  oriented  to  the  area  around  the  target.  It  »s 
in  this  area  that  the  planners  flexibility  to  consider  alternative  routes  is  most  limited  because  ho 
must  penetrate  to  the  target.  Outside  the  target  area  (i.e.,  in  the  en  route  portions  of  his  profile)  he 
has  great  latitude  in  moving  the  flight  path  away  from  areas  of  high  threat  density. 

The  planner  may  choose  a  circular  area  around  the  target  with  any  radius  up  to  BO  miles.  He  may 
well  use  the  EOB  review  displays  to  select  the  optimum  area  radius.  Since  the  routine  imposes  a 
square  grid  with  a  constant  number  of  cells  within  the  circular  area  for  scoring  purposes,  it  is 
clear  that  the  larger  the  circle,  the  coarser  the  grid  and,  therefore,  the  less  precise  the  scoring 
will  be.  The  planner  enters  the  radius  boundary  (in  miles)  in  the  appropriate  spot  on  the  A/M 
display. 


Since  scoring  Is  speed  and  altitude  dependent,  he  must  also  enter  an  ingress  altitude  and  velocity 
«  well  as  an  egress  altitude  and  velocity.  The  planner  also  has  the  capability  *o  specify  an  Initial 
Point,  or  IP.  for  his  attack  on  the  target.  Ho  enters  his  I.P.  via  light  pen  (Seo  the  m*\t  graphic 
display).  Finally,  the  planner  may  specify  whether  he  wishes  to  designate  certain  points  around 
the  circle's  perimeter  to  be  excluded  as  ingress  or  egress  points. 
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The  fif^jhtc display  indicates  the  results  of  the  planner's  use  of  his  light  pen  to  designate  an  IP  and 
prohibited  points. 
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The  processor  now  ones  the  grid  and  the  scoring  routine  to  find  the  best  routes  into  the  target 
from  the  perimeter  and  from  the  target  out  to  the  perimeter  using  the  following  rules: 

1.  If  no  IP  Is  specified*  the  computer  will  first  find  the  three  best  routes  into  the 
target. 

2.  It  will  then  find  the  best  route  out  for  each  of  the  three  ingress  routes  with  the  limits 
tion  that  no  egress  route  will  be  considered  whose  first  leg  requires  a  n  n  tighter  than 
120°  at  the  target. 

3.  Isis')  route  will  begin  or  end  at  a  prohibited  point. 

4.  Each  inbound  and  outbound  route  will  have  no  more  than  one  turn  or  bend  in  it  ami 
that  turn  will  be  no  sharper  than  t20°. 

5.  If  an  IP  is  chosen,  the  above  rules  still  apply  except  that  a  fourth  route  using  the  IP  will 
be  generated. 

Simultaneously,  the  alphanumeric  display  presents  the  data  on  each  route  including  the  score. 


The  planner  now  uses  his  Route  Modification  capability  to  complete  the  route  to  and  from  nit 
selected  airbase.  The  new  route  may  now  be  scored  for  comparison  with  any  other  route 
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For  scenario  purposes,  the  planner  has  chosen  the  route  he  planned  manually.  This  route  is  shown 
in  the  graphic  display,  fly  activating  a  function  switch  labelled  FLIGHT  PLAN  SUMMARY  the 
planner  can  get  an  Alphanumeric  display  as  shown.  This  display  was  generated  within  the  com¬ 
puter  at  the  time  the  ROUTE  PLANNING  function  button  was  activated.  It  was  continuously 
modified  each  time  the  planner  made  a  change  in  the  route,  This  display  not  only  contains  the 
specifics  of  each  leg  in  terms  of  nodes,  modes,  attitude,  Mach  and  thrust  but  also  contains  data 
reflecting  the  length  and  leading  of  eacn  (eg. 

At  any  point  in  the  planning  process  when  the  planner  is  satisfied  with  the  route,  he  has  avail 
able  a  flight  plan  for  that  route. 
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Thenext  major  function  involves  the  fuel  analysis  of  the  mission  as  tentatively  planned.  However, 
in  order  to  perform  fuel  analysis,  the  aircraft  must  be  configured  with  its  external  stores.  So  far 
the  planner  has  only  selected  ordnance.  Still  remaining  are  such  stores  as  pods,  air-to-air  weapons 
and  external  fuel  tanks. 

The  pianner  activates  a  function  switch  labelled  OBJ  (On  Board  Jamming)  which  results  in  the 
A/N  display  shown  here.  The  planner  fills  In  the  bottom  line  as  indicated,  entering  aircraft  type, 
formation  si2e  and  whether  he  wishes  to  have  one  or  two  pods.  He  also  may  specify  any  specific 
pods  and/or  pod  settings  he  wishes  to  have  considered. 

The  planner  uses  his  light  pen  on  the  graphic  display  to  indicate  the  route  segment (s)  he  wishes  to 
have  evaluated  as  shown  by  the  "X"  s. 
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The  result  of  the  OBJ  analysis  is  as  shown  In  the  present  A/N  display.  The  computer  has  con¬ 
sidered  the  threat  along  the  selected  route  segment(s).  Only  those  threats  which  literally  do  or 
cocdd  interact  with  the  mission  aircraft  on  the  basis  of  threat  range  are  considered.  Up  to  five  dif- 
fe  it  pods  and/or  settings  are  evaluated  against  this  threat.  If  no  pods/settings  were  identified  on 
the  previous  display,  then  the  processor  uses  the  five  best  pod/settings  which  ore  In  the  inventory 
and  ranks  them  from  left  to  right  against  the  threat. 

If,  ,rom  one  to  five  pod/rstiings  were  identified,  they  are  considered  as  replacements  for  the  five 
from  the  data  base.  Selected  pod/sertings  replace  data  base  pod/settings  loginning  with  the  right 
hand  'olum.t  bn  the  case  of  one  selection). 

The  planner  ieiects  a  joci/settng  combination  by  entering  a  digit  (1  through  5)  in  the  bottom 
line.  These  numbers  refer  to  the  five  columns  reflecting  different  pods. 
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The  next  function  is  produced  via  a  function  switch  labelled  CONFIGURATION.  Activation 
of  the  switch  produces  an  A/N  display  as  shown.  Since  different  target  types  require  different 
ordnance  each  flight  must  be  separately  configured.  The  planner  first  selects  and  enters  a  target 
type  from  the  list  at  the  bottom  of  the  display.  He  next  selects  whether  he  wishes  AIM  on  the  air¬ 
craft  and  which  type.  (Leaving  the  entry  blank  excludes  AIM  from  the  configuration). 

If  OBJ  selection  was  used,  the  number  of  pods  is  shown  automatically  although  the  planner  can 
modify  this  by  overwriting.  The  type  and  setting  are  already  stored  in  the  mission  summary.  If 
only  one  pod  is  specified,  the  planner  may  if  he  wishes,  specify  a  station.  Finally,  the  planner 
enters  whether  or  not  he  wants  external  tanks.  Leaving  the  entry  blank  means  no  tanks;  entry 
of  a  1  means  a  centerline  tank;  entry  of  a  2  means  tanks  on  outboard  stations,  In  the  scenario 
cate,  no  tanks  were  included. 


At  this  point  the  processor  automatically  configures  the  aircraft  if  the  following  conditions  have 

been  met 

1.  The  number  and  type  of  ordnance  are  certified  for  the  aircraft. 

2.  There  are  stations  available  for  ail  the  stores  specified. 

3.  The  number  of  units  per  station  is  at  or  below  the  maximum  allowable  for  that 
station. 

If  any  or  all  of  these  restrictions  are  not  met,  the  planner  is  notified  to  make  necessary  changes 
If  the  stores  as  defined  result  in  an  asymmetric  loading,  the  configuration  is  accomplished  and  the 
planner  is  notified  that  the  load  is  asymmetric. 

The  configuration  display  aHo  contains  the  weight  and  drag  factor  for  each  station.  I  f  the  drag  fac 
tor  it  variable  by  spaed  and/or  wing  sweep  <e.g„  on  the  Flit)  the  worst  drag  on  the  entire  flight 
Is  shown.  If  the  total  weight  of  the  stores  plus  the  aircraft  weight  exceeds  the  permissible  take  off 
weight,  the  planner  is  informed  of  the  extent  of  overage. 


Now  that  configuration  is  complete,  activation  of  the  FUEL  CALCULATION  function  switch 
produces  this  alphanumeric  display.  All  the  data  shown  are  calculated  except  for  the  reserve. 
The  planner  specifies  whether  ha  withes  the  aircraft  to  arrive  home  with  an  IFR  or  VF  R  reserve. 
Actual  quantities  for  these  reserves  am  stored  in  the  processor. 
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In  the  scenerlo,  the  fu«l  on  the  «lrcr«ft  was  not  adequate  to  fly  the  planned  profile.  The  com¬ 
puter,  having  determined  that  there  wee  insufficient  fuel,  generated  the  A/N  and  graphic  displays 
shown  here. 


The  A/N  display  present*  the  basic  aircraft  data  plus  the  information  that  the  fuel  was  inade¬ 
quate.  It  alio  Identifies  the  leg  and  point  *t  which  the  specified  reserve  is  reached.  The  point  is 
located  on  the  graphic  display  by  the  letter  "M."  In  addition,  the  alphanumeric  display  provides 
basic  tanker  date  Including  numbers  of  aircraft,  equipment  type  and  call  signs.  The  location  and 
identification  of  the  individual  tankar  orbits  am  shown  on  the  graphic  display. 

The  planner  may  select  either  outbound  refueling,  inbound  refueling  or  both.  A  refueling  track 
white  #n  route  to  dm  target  is  selected  by  entering  the  desired  number  in  the  space  labelled 
ENTER  TANKER  1.  The  entry  of  "2“  selects  Blue  track.  If  the  planner  wished  further  refueling 
on  hit  way  home,  he  would  enter  a  digit  in  the  space  It.  jailed  TANKER  2. 

If  die  planner  did  not  went  to  refuel,  he  could,  of  coures  change  hit  route,  change  h  is  speed  on 
one  or  more  tegs,  or  reduce  his  stone.  The  affects  of  thaea  options  could  also  be  reviewed  by  recal¬ 
culating  fuai  under  the  ehangsd  condition. 
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Selection  of  3  tanker  orbit  (or  two)  results  in  the  generation  of  the  tanker  requirement  which  can 
be  given  to  the  tanker  planner  or  SAC  liaison  officer  «  « refueling  requirement 
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At  this  point,  the  planner  uses  his  route  modification  capability  to  add  the  refueling  leg  to  the  route 
profile.  He  must  not  only  modify  his  ground  track  but  he  must  also  be  sure  to  change  the  mode  of 
the  refueling  leg  to  FUEL.  The  effect  of  the  changes  Is  shown  both  graphically  by  the  addition  of 
a  new  leg  and  alphanumerically  by  the  changes  to  the  flight  plan  as  shown. 

If  the  planner  wishes,  at  this  point  he  may  recalculate  the  fuel  expenditure  including  the  re¬ 
fueling  leg  and  the  refueling  Itself. 
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TACS  COMMAND  GUIDANCE 

ALL  FIT!  PENETRATING  RNK  AIRSPACE  KILL  BEWAT  TO  A42  CMC  XING  37  PARALLEL. 
FllCa  MIMH4  IACNUP  117.7.  CALL  M8N:  MAIL  IAS. 

ICREB  MtlAKK  MODE  1  CODE  IKS 

ALL  ELTt  OCMRTMN  TAE6U  NORTON  UNO  KILL  REPORT  TO  Ml  CUP. 

FREQ.  ttM-MM  BACKUP  W.7.  CALL  MSN:  PAT  CAT. 

RADAR  ABUT  MANDATORY  POR  TANNER  RENDEZVOUS 
PRIMARY  CONTROL  Ml  CALL  «3N  AND  PRES  AS  ABOVE- 


The  final  activity  with  respect  to  this  mission  involves  the  assignment  of  TACS  units  to  the  various 
iegs  of  this  mission  profile.  The  planner  first  may,  if  he  wishes,  review  the  command  guidance  re¬ 
lating  to  TACS  assignment  The  TACS  assignment  process  is  initiated  by  a  TACS  function  switch. 
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The  planner  next  reviews  the  status  of  the  TAGS  elements. 
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MODE  1  ITANMV 
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He  may  elio  review  the  communications  frequency  end  IFF/SIF  data  for  the  day. 
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The  planner  uses  the  A/N  display  as  shown  to  assign  the  various  legs  of  the  flight  to  the  CRC's  and 
CflP's.  Beginning  with  the  first  node,  he  enters  the  first  and  last  node  numbers  for  the  tegs  which 
he  desires  to  assign  to  a  particular  station.  He  then  enters  the  code  number  for  that  station  from 
the  list  on  the  right  hand  side  of  the  display.  Coordination  between  legs  and  stations  is  accom¬ 
plished  through  observing  the  graphic  display. 
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This  A/N  display  presents  the  completed  mission  summary  table  for  the  mission  against  the 
Kwangju  POL  area.  Comparison  of  this  display  with  the  one  shown  earlier  on  page  5  will 
show  that  the  force  data  has  been  completed  and  that  the  dashes  reflecting  elements  of  the 
plan  have  been  replaced  by  asterisks.  The  planner  may  review  any  element  of  his  plan  by 
entering  the  appropriate  code  number  in  the  bottom  line.  The  flight  plan  may  be  reviewed 
by  activating  the  FLIGHT  PLAN  SUMMARY  function  button. 

If  the  planner  is  satisfied  with  the  pian,  it  is  returned  to  the  data  base  for  future  use. 
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Evaluation  and  planning  of  Stand-off  support  jamming  can  be  achieved  either  by  manual  or 
by  automatic  trial  and  evaluation  processes.  The  planner  makes  an  initial  selection  of  a  mission 
to  be  supported.  The  SOJ  program  then  selects  and  displays  those  EW/GCI  radars  which  can 
detect  and  track  the  mission  aircraft.  The  program  also  computes  and  displays  a  penetration 
contour  for  all  EW/GCI  radars.  This  contour  shows  the  points  of  first  detection  for  penetration 
into  the  area  of  interest. 
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Whan  the  planner  chooses  the  manual  SOJ  mode  the  alphanumeric  display  is  formatted  so  as  to  en¬ 
able  manual  placement  of  orbits  and  the  assignment  of  aircraft  and  jammer  configuration. 

With  his  light  pen  the  planner  creates  an  orbit  of  any  length  and  orientation  at  any  position  he 
chooses  on  the  graphic  display.  On  the  A/N  display  he  assigns  an  aircraft  type,  jammer  preset 
configuration  and  altitude  for  each  orbit.  After  each  individual  orbit  assignment  the  effect  of  this 
particular  jamming  assignment  is  shown  by  0 )  a  change  in  the  shape  of  the  penetration  contour 
and  (2)  a  numerical  summary  on  the  A/N  display. 

The  A/N  display  Illustrates  that  2  EB66B  aircraft  are  assigned  at  30K  ft.  with  presets  a  1  used 
and  one  EB68E  aircraft  assigned  at  30K  ft.  using  presets  #4.*  A  maximum  of  16  orfjits  can  be 
evaluated.  The  orbits  and  the  resultant  penetration  contour  are  illustrated  on  the  graphics.  The 
wet  and  dry  exposure  values  for  each  EW/6CI  radar  are  illustrated  on  the  A/N  display.  Exposure 
values  are  reduced  by  jamming  and  a  value  of  zero  indicates  drat  the  radar  will  never  detect  and 
track  the  mission  aircraft 
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The  effectiveness  of  assigned  support  jamming  is  automatically  summed  and  displayed  by  radar 
type.  These  data,  as  shown  on  the  "SOJ  Effectiveness  vs  EW/GCI  Type"  A/N  display,  are 
available  for  further  analysis.  This  A/N  display  may  also  be  used  to  initiate  computation  and 
display  options  of  various  types.  For  example,  the  planner  may  specify  an  arbitrary  exposure 
value.  The  graphic  display  then  presents  only  those  radars  which  can  equal  or  exceed  this 
detection  and  tracking  capability  in  the  existing  jamming  environment.  The  planner  may  also 
wish  to  see  only  those  radars  which  are  individually  responsible  for  the  displayed  penetration 
contour  and  which  must  therefore  be  attacked  or  further  jammed  If  initial  detection  is  to  be 
further  delayed. 

Another  option  Is  the  capability  to  limit  the  display  to  specific  radars  or  to  all  radars  of  a  given 
type  and  the  penetration  contour  associated  with  the  specified  choices.  The  graphic  display  illus 
trates  the  planned  selection  of  aii  TB  radars.  Notice  that  the  associated  penetration  contour  has 
now  been  reduced  to  two  separate  small  dosed  areas. 

Similarly  the  planner  might  type  in  the  pin  numbers  of  sevoral  specific  radars  comprising  a  single 
EW  net.  He  would  then  be  able  to  visualize  and  plan  jamming  activities  against  that  net.  Mixtures 
of  specific  radars  of  different  types  are  permissible.  The  planner  uses  the  "Restore"  option  to 
recover  the  display  of  ell  EW/GCI  radars. 

When  the  number  of  displayed  radars  is  limited  the  wet  exposure  values  still  truly  reflect  the  ef¬ 
fects  of  all  assigned  SOJ  support  jamming  vehicles.  The  penetration  contour,  however,  demon¬ 
strates  this  cumulative  jammi  >g  applied  against  only  those  specific  radars  or  radar  types  requested. 
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Ail  ^he  aforementioned  capabilities  ere  integrated  with  the  Automatic  Orbit  Selection  (AOS) 
process.  The  planner  may  at  any  time  call  the  AOS  program  for  assistance  to  determine  the  best 
position  and  best  jamming  configuration  to  achieve  desired  (specified)  results.  If  the  planner 
wishes  to  limit  results  to  specific  radars  or  to  radars  of  a  given  type,  he  first  makes  these  selections. 

In  the  AOS  program  the  planner  can  light  pen  the  location  for  as  many  as  five  different  orbits  for 
trial  evaluation.  He  can  select  either  a  specific  combination  of  aircraft  types  and  jamming  con¬ 
figurations  or  simply  ask  for  analysis  of  all  available  aircraft  and  jamming  configurations.  The 
AOS  program  then  analyzes  ail  requested  combinations  and  displays  to  the  planner  the  relative 
benefits  of  each.  The  planner  may  then  see  which  orbit  position(s)  and  aircraft/jammer  configura¬ 
tion^)  best  achieve  his  intended  purpose,  The  planner  can  then  select  one  or  more  of  the  com¬ 
binations  for  assignment  and  the  program'automatically  updates  all  computations  and  displays 
to  reflect  these  assignments. 

The  AOS  program  also  operates  in  a  "Delete"  mode.  Should  cancellation  or  reassignment  of 
vehicles  be  required  the  computer  uses  this  mode  to  test  each  existing  assignment  and  determines 
which  one  makes  the  smallest  contribution. 
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EC*  EFFECTIVENESS 

1}  LIGHT  FEN  THREAT  2)  LI6HT  FEN  STRIKE  ROUTE  ANALYSIS  K)INT(S) 
EFFECTIVENESS  0FT10NS:  TOLERANCE: 


t)  TONE  NAME  HISTORY  (1  AHALVStS  FOINTSJ 

2)  EARLY  LATE  ANALYSIS  (2  FOINTS) 

3)  NWWTHROtlSH  CONTOUR  (2  FOINTS) 

4)  FORMATION  ANALYSIS  (1  FOWT1 

I)  TIME  NAME  HISTORY  FOR  SURNTHROUSH  CONTOUR 
1}  SIM  SURNTHROUSH  CONTOUR, (2  FOINTS} 

SELECT  OPTIONS  SHIFT  ANO  ENTER 

EFFECTIVNESS  TOLERANCE 

1/1  SR*  H  FORMATION  I/+—OS 


1}  STANOARD 

2)  CONSERVATIVE 

3)  OPTIONAL  OS 


The  effects  of  noise  jamming  from  either  support  vehicles  or  on-board  jammers  can  be  computed 
and  displayed  utilizing  the  "Burnthrough"  concept.  The  planner  may  select  any  radar  and  request 
results  for  any  available  jammer  configuration.  The  burnthrough  range  (radar  range  capability  in 
the  presence  of  jamming)  is  overlayed  on  the  graphic  display  when  the  planner  selects  (1)  the 
radar  of  interest,  (2)  the  region  over  the  flight  path  of  interest  and  (3)  the  jamming  configuration. 

The  expanded  graphic  Display  as  shown  illustrates  the  polar  burnthrough  display  option.  The 
computations  behind  this  display  encompass  variable  radar  cross  section;  summation  of  all  indi¬ 
vidual  jammer  contributions  vie  relative  position  to  the  radar  boresight  axis;  three  dimensional 
antenna  patterns  for  the  victim  radar  and  the  jammers,  and  variation  of  parameters  to  include  the 
effects  of  aircraft  turning. 


ECM  EFF ICTIVEMESS 

1)  LIGHT  FEW  THREAT  2)  LIGHT  FEN  STRIKE  ROUTE  ANALYSIS  POINT'S) 
EFFECTIVENESS  OPTIONS;  TOLERANCE; 


1)  TIME  RANGE  HISTORY  (2  ANALYSIS  POINTS) 

2)  EARLY  LATE  ANALYSIS  «  POINTS) 

I)  SURMTHROUGH  CONTOUR  12  POINTS) 

4)  FORMATION  ANALYSIS  (1  POINT) 

$)  TIME  RANGE  HISTORY  FOR  IUANTHROUQH  CONTOUR 
«)  SOI  RURNTHROUQH  CONTOUR  (2  POINTS) 

SELECT  OPTIONS  SHIFT  AND  ENTER 

EFFECTLESS  TOLERARCS 

1/1 RRN  M.  FORMATION 


1)  STANDARD 

2)  CONSERVATIVE 

3)  OPTIONAL  OR 


Burrl through  results  may  also  be  displayed  on  expanded  scale  in  the  form  of  a  "time  range  his¬ 
tory."  This  option  is  illustrated  on  the  graphic  display  for  a  TWS  radar  containing  two  separate 
beams.  The  program  can  display  the  range  capability  for  up  to  6  individual  beams.  Mission  time 
is  displayed  on  the  horizontal  axis.  The  time  and  duration  of  burnthrough  are  determined  by 
the  intersection  (if  any)  of  the  aircraft  range  curve  with  the  respective  range  capability  for  each 
of  the  radar  beams. 
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The  final  slide  represents  a  plan  review  and  coordination  technique  referred  to  as  Time  Sequence 
Review  of-  TSR.  After  missions  have  been  planned  against  all  the  requirements,  the  planner  may 
bring  up  a  graphic  display  of  all  the  planned  missions  on  a  timed  basis.  The  planner  specifies  a 
starting  time  and  an  ending  time,  e.g.,  0740  to 0900.  The  computer  then  retrieves  from  the  data 
base  all  mission*  which  will  be  airborne  during  that  period. 

Beginning  at  0740  it  displays  the  location  of  ail  missions  airborne  at  that  time.  It  then  steps 
through  the  specified  time  period  in  selected  time  increments.  The  size  of  the  step  may  also  he 
varied.  It  continually  displays  the  location  of  each  airborne  mission  at  each  time  increment  until 
the  Stop  Time  of  0900  is  reached.  Whenever  threats  are  encountered  they  are  also  displayed.  The 
stepping  is  either  automatic  or  manual,  as  instigated  by  the  planner.  Choices  are  handled  via 
function  buttons. 

In  parallel  with  each  change  in  the  graphic  display,  the  A/N  display  indicate*;  which  flights  are 
airborne,  the  Lat/Long  of  each  position  and  its  altitude  data.  Any  space/time  conflicts  between 
two  missions  result  in  an  automatic  alarm  to  the  operator  who  can  stop  the  process  and  deter¬ 
mine  which  mission  to  change  and  how  to  change  it.  This  capability  may  also  be  used  to  evaluate 
the  success  achieved  in  coordinating  various  missions. 

Complete  design  and  programming  specifications  for  the  Mission  Planner  Breadboard  are  available 
in  Data  Systems  Division's  Documents  Technical  Report,  B003  and  Specification  i 34000  100, 
respectively. 
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Mission  Planner  Breadboard  Applications  to  RPV  Planning 


Subparagraph  4.  1.  1.3.3.  1  of  Contract  F30602-71-C-0015,  Change  C, 

6  July  1972,  required  that  a  subset  of  those  existing  software  programs  which 
satisfy  the  RPV  command  and  control  requirements  should  be  identified  as 
follows: 

a.  Target  Characteristic  Review:  A  mission  and  targets  may  be 
selected  for  detailed  planning.  Additional  targets  can  be  added 
to  the  current  data  base  which  are  considered  to  be  more  typi¬ 
cal  targets  for  the  currently  proposed  types  of  RPVs  and  their 
payloads.  Details  of  the  assumptions  for  target  types  and  mis¬ 
sions,  which  were  used  in  the  test  results  of  the  RPV  demon¬ 
stration,  are  described  in  Subsection  4.  5.  Once  the  RPV  mis¬ 
sion  and  target  lists  have  been  input  to  the  data  base  and  a  tar¬ 
get  (mission)  has  been  selected,  the  planner  may  analyze  the 
previous  mission  as  it  is  presently  done  for  manned  aircraft. 

The  only  critical  modification  is  the  addition  of  the  type  of 
vehicle  which  flew  the  earlier  mission;  e.g. ,  manned  aircraft 
or  RPV. 

b.  Aircraft/Ordnance  Selection  and  Assignment:  The  planner  may 
select  the- type  of  ordnance,  the  type  and  number  of  vehicles, 
and  assign  a  resource  location  lor  each  target.  Both  data  base 
changes  and  minor  program  modifications  are  required  to 
accommodate  resource  selection  and  assignment  for  RPVs, 
Specifically,  for  ordance  selection,  new  JMEM  tables  for  the 
various  vehicles  need  to  be  developed,  stores  in  the  data  base, 
and  included  In  the  ordnance  inventory  list.  Similarly,  data 
base  changes  must  be  incorporated  to  include  launch  site  location 
data  and  data  on  the  availability  and  numbers  of  RPVs  at  the  var¬ 
ious  RPV  units  and/or  launch  sites,  In  the  breadboard  system,  a 
limit  of  four  different  types  of  manned  aircraft  are  available  for 
resource  selection.  The  use  of  the  breadboard  for  RPV  planning 
requires  minor  program  modification  to  replace  one  of  the  four 
manned  aircraft  by  an  RPV . 

c.  Call.  Sign  Assignment:  The  planner  can  assign  call  signs  to  the 
RPVlan3  relay)  missions  using  the  technique  currently  in  vise, 
tf  squadron  numbers  and/or  locations  are  modified,  the  call  sign 
data  base  must  be  updated. 

d.  EOB  Review;  The  planner  may  review  the  location  and  effective 
area  of  any  enemy  threat  in  the  data  base.  As  with  manned  air¬ 
craft,  this  review  may  be  limited  to  those  threats  intersecting 
the  RPV  profile.  No  changes  are  required. 

e.  Semi-automatic  Route  Selection:  The  planner  may  select  an 
Ingress  and  egress  route  to  the  target.  He  may  also  specify  a 
speed/altitude  profile.  The  planner  may  also  modify  the  route 
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semi-automatically  and  evaluate  the  results  of  these  modifica¬ 
tions.  Data  base  changes  must  be  made  to  reflect  the  perform¬ 
ance  characteristics  of  an  RPV  included  as  one  of  the  vehicles; 
e.g. ,  Mach  number,  altitude,  and  speed  limitations. 

f.  Safety  Analysis;  The  selected  route  may  be  evaluated  to  give  a 
relative  safety  evaluation  based  on  the  threats  encountered.  A 
"Relative  Safety"  score  of  the  route  and  the  least  safe  segment 
can  then  be  displayed.  The  route  can  be  altered  and  the  alter¬ 
nate  route  "Safety  Score"  can  be  computed  and  corto pared  with 
the  original  route’s  score.  Changes  in  the  route  safety  analysis 
require  an  update  of  the  data  base  to  reflect  new  weighting  fac¬ 
tors  for  the  various  threats  to  be  used  in  the  scoring  algorithms. 
Modifications  to  reflect  extremely  low  terrain  following  routes 
may  also  be  necessary.  The  relative  effectiveness  of  each 
threat  type  must  be  examined  as  they  affect  RPVs. 

g.  Automatic  Route  Selection;  The  program  may  automatically 
select  the  three  heat  Ingress  and  ogress  routes  for  the  target 
within  a  radius  of  50  nm  using  the  safety  analysis  algorithms. 

h.  TAGS  Assignment;  Tactical  Air  Control  System  Station  Assign- 
me nt s  can  oe  perTor me d  on  a  leg -by -leg  basis  for  the  entire 
route. 

i.  Effectiveness  Analysis;  This  ECM  effect  analysis  will  consist 
of  the  following  programs; 

1,  Burnthrough  and  Time -Range  History;  Self-protect  ECM 
may  be  evaluated  by  calculating  and  displaying  burnthroughs, 
contours,  and  time  range  histories. 

2.  Formation  Analysis;  The  cooperative  effect  of  gelf-proiect 
ECM  may  be  evaluated  for  several  vehicles  flying  in 
formations. 

I,  Standoff  Jamming  (SOJ)  Analysis;  It  will  be  possible  to 

assign  and  evaluate  SOJ  vehicles  to  support  RPV  missions, 
or  to  assign  and  evaluate  RPV  vehicles  for  standoff  jamming 
missions, 

4.  Special  Support  Jamming  (SSJ)  Analysis:  It  will  be  possible 
to  assign  and  evaluate  RPV  vehicles  for  support  jamming 
roles. 

5.  On-Board  Jamming  (OBJ)  Analysis:  It  will  be  possible  to 
evaluate  the  effectiveness  of  OBJ  against  a,  large  environ¬ 
ment  of  SAMs.  Tills  function  requires  only  an  update  of  the 
data  base.  The  Initial  change  is  to  include  a  radar  cross 
Section  table  for  the  RPVs  as  a  function  of  aaimuth  and 
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elevation  angles.  In  addition,  for  formation  analysis, 
different  threat  dimensional  spacing  must  be  added  to  the 
formation  table.  If  any  new  on-board  jamming  capability 
is  to  be  considered,  the  characteristics  of  the  jamming  con¬ 
figuration  must  be  added  to  the  available  equipment  list. 

j.  Time -Sequence  Review  (TSR):  TSR  allows  the  planner  to  review 
Sis  total  planning  effort.  He  may  view  the  total  planned  mis¬ 
sions  as  a  series  of  time  frames.  In  addition,  he  may  see  the 
SOJ  and  SSJ  missions  as  well  as  the  threats  that  interact  with 
the  missions.  No  changes  are  required  for  Time  Sequence 
Review. 

4.4  BREADBOARD  SYSTEM  EXTENSIONS  AND  MODIFICATIONS  TO 
ACCOMMODATE  ADDITIONAL  COMMAND  AND  CONTROL  FOR 
RPVs 

There  are  three  general  areas  in  the  Command  and  Control  of  RPVs  where 
the  present  Mission  Planner  Breadboard  could  be  modified  and/or  extended 
to  accommodate  additional  functions.  These  three  areas  include  additional 
pre-planning,  mission  monitoring,  and  near-real  time  command  and  control 
functions.  The  following  subsections  briefly  describe  some  functions  in  each 
of  the  areas,  as  well  as  how  they  might  be  implemented  within  the  structure 
of  the  present  breadboard.  Thses  functions  are  either  new  or  require  exten¬ 
sive  modification  to  existing  MPBS  implementation. 

4.4.1  Additional  Preplanning 

4.4.  1.  1  Terrain  Following  Route  Planning 

One  of  the  prime  tactics  presently  considered  for  RPVs  is  low-level  ingress/ 
egress  utilizing  "terrain  hugging1  wherever  feasible.  The  basic  building 
blocks  for  the  development  of  an  automatic  and/or  semiautomatic  terrain 
following  route  selection  based  upon  route  safety  already  exists  in  the  Mission 
Planner  Breadboard  System.  These  building  blocks  are  terrain  masking, 
route  safety  analysis,  and  automatic  route  selection. 

In  the  present  implementation  of  terrain  masking,  a  set  of  masking  angles  and 
ranges  is  stored  for  each  threat.  These  data  are  available  to  evaluate  the 
route  safety  score  of  the  strike  force  to  the  threats  based  upon  a  given  route 
and  altitude.  Also,  by  utilizing  the  terrain  data,  one  could  expand  these  pro¬ 
grams  to  determine  the  route  safety  score  for  any  given  route  based  upon  the 
strike  force's  flying  X  number  of  feet  above  terrain.  Once  these  algorithms 
have  been  developed,  a  planner  could  manually  select  alternate  routes  until 
he  is  satisfied  with  the  route  safety,  or  the  technique  could  be  incorporated 
in  automatic  route  selection. 

Automatic  terrain  following  route  determination  would  take  considerable  com¬ 
putational  time  and  require  a  large  amount  of  storage.  Studies  are  presently 
underway  to  reduce  the  time  and  storage  requirements.  It  is  important  to 
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note,  however,  that  the  implementation  of  the  techniques  in  a  straight  forward 
manner  on  the  Breadboard  could  be  an  invaluable  simulation  tool  to  test  the 
sensitivity  of  various  parameters  such  as  accuracy  of  navigation  data  required, 
required  digital  terrain  data  quantisation,  accuracy  of  threat  locations,  and 
other  variables  associated  with  the  problem. 

4.4.  1.2  Fuel  Calculations 

Changes  and  additions  to  the  present  fuel  calculations  which  are  necessary  for 
RPV  planning  include  design  and  programming  of  the  following  capabilities: 

a.  Integration  of  the  terrain  following  mode  of  operation  into  the 
speed/altitude/fuel  consumption  calculations  will  be  required. 

b.  Certain  missions  {ECM  in  particular)  may  require  on-station 
orbiting  or  loiter  patterns.  For  these  missions,  a  special  tech¬ 
nique  is  needed  wherein  the  planner  can  simply  input  the  pattern 
type,  on -station  position,  and  time  duration.  The  computer 
would  then  automatically  compute  the  on-station  flight  path  time 
history  and  fuel  consumption  for  this  segment.  In  the  case  of 
reconnaissance  and  ECM  missions,  the  on -station  flight  path 
dynamics  would  also  be  available  for  evaluation  of  payload 
effectiveness  and  timing  requirements. 

4.4.  1.  3  Dynamic  Line  of  Sight  Computation  and  Display 

Long  range  command,  control  communication  links  from  fixed  sites  which 
are  subject  to  LOS  limitations  may  be  rapidly  evaluated  using  current 
Mission  Planner  terrain  masking  algorithms  together  with  the  capability  to 
update  the  mission  tracks  with  status  reports,  A  desirable  expansion  of  the 
present  fixed  site  (CRC/CRP)  capability  would  be  to  enable  terrain  interfer¬ 
ence  calculations  between  airborne  C&C  plarforms  and  RPVs  (or  other 
vehicles)  with  arbitrary  flight  profiles  for  each  element.  RPVs  on  low  alti¬ 
tude  fLightpath  segments  will  be  subject  to  LOS  blockage  by  the  terrain  and 
the  anticipation  of  when,  and  for  how  long,  these  interrupts  oc  cur  tan  be  vital 
to  mission  success.  The  preplanning  of  an  airborne  command  and  control  to 
supervise  multiple  RPV  elements  is  a  complex  problem  itself  and  any  require¬ 
ments  for  rapid  real  time  replanning  to  include  terrain  masking  calculations 
would  be  an  almost  impossible  task  to  perform  manually. 

This  capability  extension  will  allow  the  planner  to  identify  any  two  flight  ele¬ 
ments  and  request  LOS  calculations  between  the  respective  vehicles  for  any 
time  period.  The  intervals  of  terrain  blockage  (if  any)  can  be  displayed  on 
the  geographies  display  by  interruption  (blanking  out)  of  the  affected  flight 
path  segments.  The  corresponding  times  of  interrupt  can  be  displayed  on  the 
A/N  and  therefore  be  available  for  hard  copy  print  out.  All  the  rerouting 
options  would  be  available  to  the  planner  so  that  he  may  replan  the  route/ 
profile  of  either  vehicL  ,  if  necessary,  to  achieve  the  desired  results. 
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4.4. 1.4  Data  Base  Update 


There  are  elements  of  the  current  MPS  data  base  which  are  static  predictions 
used  for  preplanning  purposes  but  which  assume  a  dynamic  nature  when  used 
for  in-flight  replanning.  Some  of  the  current  flight  safety  and  mission  suc¬ 
cess  factors  which  warrant  input  of  new  data  during  mission  progress  include 
the  following: 


a.  Weather  hazards  and  cloud  layer  structure. 

b.  Changes  in  SAM  and  AAA  posture. 

c.  Changes  in  restricted  flight  zones. 

To  facilitate  the  input  and  use  of  these  data  changes,  a  temporary  file  struc¬ 
ture  can  be  created.  The  operator  would  input  from  the  keyboard  directly 
into  these  files.  Each  program  using  data  of  this  type  could  be  modified  to 
access  the  temporary  files  prior  to  execution  of  the  required  function. 

4.4.2  In  Flight  Replanning 


4.  4.  2.1  Schedule  Modification 

The  MPS  was  not  implemented  to  operate  with  real  time  inputs,  however,,  with 
minor  modification,  the  MPS  could  be  used  for  execution  or  simulation  of  a 
wide  range  of  C&C  operations  type  problems.  In  the  present  system  all  flight 
position  timing  is  computed  forwards  and  backwards  from  the  input  TOT 
requirement.  Accordingly,  when  route  modifications  are  introduced  during 
the  planning  cycle,  schedule  times  are  adjusted  as  necessary.  To  best 
achieve  the  real  time  replanning  capability,  it  is  desirable  to  add  the  option 
of  accepting  mission  progress  reports.  When  such  inputs  are  received  the 
flight  path  following  program  (Time  Sequence  Review  or  TSR)  would  then  use 
the  input  time  versus  position  data  up  to  the  last  received  values.  Beyond 
the  last  input  data  point,  the  remainder  of  the  flight  path  position  versus  time 
sequence  would  be  computed  using  checkpoints  from  the  plan  and  the  computed 
ground  speed  values.  With  the  input  of  such  data  the  TSR  program  may  then 
be  placed  in  operation,  and  the  operator  will  see  on  the  geographies  display 
the  actual  and  preplanned  flight  progress  versus  mission  time.  In  response 
to  visual  deviations,  the  planner/controller  may  wish  to  redirect  the  mission 
to  overcome  anticipated  problems  after  assessing  factors  of  flight  safety  and 
potential  mission  success.  The  type  of  assessments  the  planner/controller 
may  wish  to  make  and  which  can  be  provided  by  the  MPS  breadboard,  include 
the  following; 

a.  What  is  the  impact  of  the  current  position  reports  on  the  TOT? 

b.  Can  the  route /profile  and  speeds  be  modified  to  achieve  the 
desired  TOt  ? 

c.  If  route  modifications  are  made  will  the  route  safety  be 
severely  compromised? 
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d.  If  route/speed  deviations  are  made  is  the  fuel  adequate? 

Can  the  flight  reach  an  alternate  base  ? 

4. 4. 2. 2  Techniques  of  Adjustment  and  Replanning 

Given  the  ability  to  accept  mission  progress  reports,  various  assessments 
and  adjustments  can  be  made  with  the  MPS  used  in  the  following  manner. 

a.  Monitoring  the  impact  of  flight  profile  deviation;  the  TSR  pro¬ 
gram  is  entered  and  either  manually  or  automatically  stepped 
to  advance  to  mission  time.  In  the  TSR  program  a  small  seg¬ 
ment  of  each  flight  path  is  shown  which  indicates  present  posi¬ 
tion  and  path  made  good  over  the  last  few  minutes.  By  inspec¬ 
tion  of  the  TSR  display  the  operator/controller  can  immediately 
«ee  divergences  between  planned  and  actual  flight  paths.  Mis¬ 
sion  time  (or  simulated  real  time)  is  displayed  on  the  bottom  of 
the  CRT.  Flight  path  detours  or  decays  can  be  assessed  as  to 
their  impact  on  the  mission  by  merely  noting  the  time  differ¬ 
ence  required  for  the  respective  tracks  to  reach  the  same  posi¬ 
tion  (assumes  that  the  deviated  mission  regains  ex  position  on  the 
planned  track  and  follows  the  preplanned  check  point  and  speed 
sequence). 

b.  Assuming  that  a  significant  deviation  has  occurred,  the  planner/ 
controller  may  elect  to  follow  any  one  of  several  courses  of 
action  depending  on  the  mission  priority  and  nature  of  deviation. 
For  example: 

1.  The  planner/controller  may  accept  the  schedule  variance 
and  choose  only  to  verify  that  fuel  requirements  are  met. 

In  this  case  he  would  activate  the  FUEL*  program  and 
would  receive  an  alphanumeric  summary  of  the  refueling 
plans  (if  any)  and  a  "go"  or  "no  go"  report  on  fuel  adequacy. 

If  insufficient  fuel  is  available,  the  geographies  display  will 
mark  on  the  flight  path  the  position  of  fuel  exhaustion. 

2.  The  planner/ controller  may  elect  to  modify  the  route  in 
order  to  conserve  fuel  or  to  attempt  to  achieve  the  desired 
schedule.  In  this  case  he  would  activato  the  MODIFY  ROUTE 
program  and  would  now  be  able  to  manually  modify  both  the 
path  and/or  the  speed  altitude  profile  as  deemed  appro¬ 
priate.  Upon  completion  of  the  route  modification,  he  could 
then  return  either  to  the  TSR  or  FUEL  programs  to  verify  that 
his  objective  has  been  achieved.  Significant  changes  in  the 
route  profile  may  adversely  affect  mission  success  if  the  num¬ 
ber  or  type  of  threats  encountered  changes.  To  assess  this 


4* 

The  current  fuel  programs  include  F-4,  F-105,  A-7,  and  F-lll  aircraft. 

Separate  fuel  and  ordnance  loading  programs  are  required  for  each  vehicle 
type. 
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possibility  the  ROUTE  SAFETY  program  will  provide  an 
alphanumeric  summary  and  comparison  of  the  preplanned 
route  with  the  newly  created  route.  The  safety  analysis 
provides  summation  figures  of  merit  (relative  safety  fac- 
tors)  for  the  overall  mission  and  for  each  type  of  hostile 
threat.  The  graphics  display  will  indicate  the  number  of 
possible  lethal  encounters  for  the  SAM  and  AAA  sites.  If 
desired,  any  of  the  ECM  programs  may  also  be  invoked  to 
assess  the  suitability  of  support  and  self  protect  jamming 
equipments. 

3.  There  may  be  a  requirement  to  direct  an  airborne  RPV 

mission  to  a  new  target.  To  enable  this  capability  requires 
an  additional  change  to  the  current  breadboard  system.  The 
reprogramming  needed  is  simply  that  which  will  retain  the 
established  flight  track  on  the  geographies  display  and 
enable  the  recall,  display,  and  selection  of  an  alternate 
target.  Having  selected  the  new  target,  the  planner/ 
controller  may  now  proceed  to  re-route  and  evaluate  the 
new  mission  using  any  of  the  techniques  available  in  the 
breadboard,  including  the  Automatic  Route  Selection  pro¬ 
gram.  He  may  also  look  at  other  aircraft  to  be  diverted 
to  the  target,  if  it  is  high  priority. 

4.4.3  Mew  Missions 

The  MPBS  was  designed  to  handle  Strike  Missions  and  a  subset  of  the  ECM 
mission.  Expanding  the  breadboard  to  support  RPV  requires  extensive  acti¬ 
vity  in  the  areas  of  planning  other  ECM  missions  and  the  Reconnaissance  mis¬ 
sion,  including  EL1NT. 

4.4  3,1  ECM  Missions 

Tb  ^  degree  of  modification  required  to  the  MPS  will  depend  on  the  type  of 
RTV  mission.  The  simplest  modifications  will  be  to  enable  planning  of  ECM 
support  since  many  of  the  ECM  effectiveness  evaluation  techniques  already 
exist  in  the  MPS.  Two  readily  implemented,  and  effective,  ECM  mission 
types  are  identified  below  as  candidates  for  early  tactical  use  of  existing  and 
forthcoming  RPV  capabilities. 

a.  ECM  MISSION  TYPE  I  -  Orbiting  RPVs  with  Noise  Jammers: 

These  vehicles  can  be  flown  to  critical  areas  and  put  into  orbit 

in  close  proximity  to  radars  to  achieve  either; 

1.  Degradation  of  the  EW/CCI  radar  net. 

2.  Degradation  of  specific  terminal  threat  SAM  and 
AAA  complexes. 
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b.  ECM  MISSION  TYPE  II  -  Chaff  Dispersal;  At  least  two  basic 
chaff  missions  can  be  identified; 

1.  Corridor  Chaff  dispersal  to  generate  long  length  screening 
paths  for  manned  penetrators.  These  same  corridors  may 
also  serve  as  confusion  and  decoy  elements. 

2.  Pattern  Chaff  for  terminal  threats.  The  patterns  may  be 
of  various  types  such  as  continuous  rings  around  the  emit¬ 
ter,  or  might  consist  of  spot  bundles  deployed  at  various 
altitudes  and  positions.  Whereas  corridor  chaff  will  be 
primarily  used  for  screening,  tire  pattern  chaff  will  also 
function  to  create  confusion  and  aid  the  track  breaking  of 
SAM  and  AAA  radars. 

4. 4.  3. 2  Reconnaissance  Missions 

This  subsection  discusses  the  data  base  requirements  and  planning  process 
for  two  types  of  reconnaissance  missions.  These  types  are  Photo  reconnais¬ 
sance  and  ELINT.  The  Advanced  Development  Mission  Planning  System  will 
include  these  mission  types  while  the  breadboard  does  not.  Thus,  in  the 
present  context  they  are  described  as  major  modification  of  the  breadboard. 

4.  4.  3. 2.  1  Photo  Reconnaissance  Missions.  Two  factors  of  the  photo  recon¬ 
naissance  mi's  s  r<m"a  re  "discussed  in  the  folio  wing  paragraphs.  These  factors 
are;  the  data  base  requirements,  and  photo  reconnaissance  mission  planning. 

a.  Data  Base  Requirements 

The  ADMPS  data  base  applicable  to  the  mission -peculiar  aspects 
of  photo-reconnaissance  includes  technical  data  on  vehicles, 
sensors,  and  targets,  as  well  as  target-associated  history  files 
and  technical  analysis  files.  The  sensor/target  technical  data 
must  include; 

1.  Recommended  sensor/target  combinations. 

2.  The  capabilities  of  sensor  installations  to  obtain  different 
kinds  of  information  at  different  resolutions  as  a  function  of 
altitude,  speed,  lighting,  direction  of  view,  visibility,  film, 
and  exposure  or  other  setting. 

3.  The  ground  coverage  of  sensor  installations  as  a  function 
of  altitude. 

4.  The  requirements  of  the  targets  for  different  sensors,  sen¬ 
sor  modes  (e.g.,  stereo),  resolutions,  directions  of  view, 
etc. ,  in  order  to  yield  various  different  kinds  of  reconnais¬ 
sance  information. 


The  target  technical  data  will  also  include  constraints  on  vehicle 
altitude,  or  vehicle  approach  or  viewing  direction,  such  as  may 
be  imposed  by  terrain  or  other  features  in  the  target  vicinity. 
Other  data  on  targets  as  well  as  vehicle  status,  availability,  and 
performance  characteristics  are  similar  if  not  identical  to  that 
for  strike  aircraft. 

b.  Photoreconnaissance  Planning 

It  is  envisioned  that  the  planner  will  call  up,  from  the  ADMPS 
data  base,  lists  of  his  assigned  targets  and  target  areas,  their 
priorities,  TOT  requirements  (especially  important  in  cases  of 
pre-  and  post-strike  reconnaissance  for  bomb  assessment  pur¬ 
poses,  and  in  cases  where  lighting  conditions  or  special  target 
activity  is  critical),  and  required  reconnaissance  information 
or  required  resolution.  These  will  have  been  generated  by 
command  sources  external  to  the  ADMPS.  He  will  also  call  up 
data  on  the  inventory  and  readiness  status  of  his  reconnaissance 
vehicles  and  sensors,  and  their  locations.  He  may  call  up 
recommended  target/sensor  combinations,  sensor/target  tech¬ 
nical  data,  references  to  file  data  on  related  past  reconnais¬ 
sance  missions,  and  references  to  file  data  on  target  character¬ 
istics  (activity  times,  resolutions  required  for  information  yield, 
local  hazards,  etc. ),  as  well  as  weather/visibility/lighting 
forecast  data. 

Based  on  this  information,  the  planner  selects  a  specific  target  (or  target 
area,  or  set  of  targets  whose  reconnaissance  requirements  may  be  met  with 
the  same  sensor  installation  on  the  same  mission)  against  which  to  plan  a 
mission.  He  then  determines  an  initial  group  of  candidate  vehicie/sensor 
combinations  (with  associated  estimated  over-target  altitudes,  approach 
directions,  area  sweep  patterns,  etc.). 

This  initial  group  of  candidates  may  be  chosen  directly  from  past  missions, 
or  from  a  data  base  recommendation  for  the  particular  target  type  and  re¬ 
quired  recce  information. 

The  initial  group  of  vehicle  sensor  candidates  may  be  reduced  or  modified  by 
the  planner's  estimates  of  route/profile  acceptability,  support  mission  avail¬ 
ability,  and  potential  mission  effectiveness  as  in  strike  mission  planning. 

The  remaining  group  of  vehicle/sensor  candidates  are  subjected  to  more 
detailed  reconnaissance  mission  planning.  Over -the -target  altitudes  and  flight 
routes,  target  area  sweep  patterns,  and  inter-target  flight  paths  are  displayed 
on  the  geographic  display.  In  particular;  geographic  constraints,  reconnais¬ 
sance  targets,  and  enemy  defenses  and  defense  coverages  are  displayed  on 
which  the  planner  can  enter  and  modify  any  tentative  mission  route.  He  may 
also  request  display  of  the  sensor  installation's  ground  coverage  swath 
along  It. 
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Planning  continues  essentially  as  it  does  £or  strike  missions.  The  only 
additional  mission-peculiar  feature  of  the  reconnaissance  planning  is  the  need 
for  TOT  coordination  with  strike  missions  which  the  reconnaissance  mission 
may  support. 

For  reconnaissance  mission  planning,  as  for  strike  mission  planning,  the 
ADMPS  prototype  provides  for  the  counting  down  of  basic  and  support  mis¬ 
sion  resources  as  they  are  assigned,  for  die  replanning  of  missions  if  the 
time-sequence  review  turns  up  conflicts,  and  for  aid  in  the  translation  of 
mission  plans  into  Fragmentary  Orders  for  automatic  printing  and 
distribution. 

4.4. 3. 2. 2  ELINT  Planning.  ELINT  missions  can  be  identified  in  two  cate¬ 
gories:  "survey11  mUsion»7  whose  objective  is  to  determine  the  content  of  the 
electromagnetic  (E/M)  environment  over  a  considerable  region,  and  "specific' 
missions,  whose  aim  is  to  collect  certain  predetermined  types  of  data  about 
specific  emitters.  Each  type  of  mission  may  ror  may  not  be  harmonized;  i.  a. , 
executed  in  coordination  with  other  types  of  missions  such  as  strike,  armed 
reconnaissance,  and  iron  hand  missions.  Since  all  recce  missions  are  con¬ 
ducted  in  response  to  collection  requirements,  all  missions  are  correlated 
to  some  extent.  An  ELXNT  mission  may  be  either  an  initial  or  confirming 
collection  effort.  Usually  (but  not  always)  the  initial  collection  mission  is 
of  the  survey  type  while  a  confirming  effort  would  "usually"  be  more 
specifically  targeted. 

Because  the  essence  of  reconnaissance  is  passive  observation,  such  missions 
are  frequently  coordinated  with  other  missions  which  serve  to  stimulate  the 
overt  actions  of  the  enemy  defensive  EM  environment.  Hence,  the  strike, 
etc.,  missions  planned  with  the  ADMPS  are  the  foil  of  the  ELINT  mission. 
Therefore,  it  must  be  planned  to  make  maximum  use  of  the  other  missions 
while  not  interfering,  nor  being  interferred  with,  (by  ECM  elements  for 
instance).  This  set  of  circunstances  is  most  reasonable  since  the  thrust  of 
much  of  the  collection  effort  is  to  identify  threats  to  strike  and  other 
penetration  missions. 

In  order  to  accomplish  coordinated  planning  of  ELINT  missions,  the  planner 
must  employ  the  functions  and  data  base  information  which  are  also  used  in 
strike,  photo  recce,  and  ECM  support  mission  planning. 

ELINT  specific  functions  are  addressed  after  the  general  situation  has  been 
established.  A  preliminary  flight  route  is  developed  to  optimize  probability 
of  detection  b>  correlating  range  capability  of  the  hostile  emitters  with  the 
sensitivity  of  his  appropriate  sensors.  The  planner  extracts  the  capability 
date  from  the  data  base  for  given  emitter  types,  and  computes  the  theoretical 
range  capability  using  the  ADMPS  computation  capabilities.  Using  the  loca¬ 
tions  provided  in  the  targeting  data  or  in  a  date  base  ROB/EOS,  the  analyst 
plots  the  theoretical  coverage  of  each  enemy  emitter.  Before  accepting  the 
theoretical  coverage,  the  planner  extracts  any  pertinent  data  from  tho  mis¬ 
sion  history  file  which  necessitates  modifications  to  the  coverage  such  as 


terrain  and  individual  emitter  capabilities.  The  planner  then  double  checks 
sensor/target  correlation  to  ensure  that  the  sensor  can  detect  the  signal  if 
the  ELINT  platform  is  in  range.  Finally,  a  mission  flight  route  is  drafted 
which  places  the  ELINT  vehicle  within  detection  range  of  his  receivers. 
Probability  of  detection  is  maximized  as  a  function  of  range,  duration  of  pur¬ 
view  and  sensitivity.  Distance  and  altitude  of  sensor,  receiver  sensitivity, 
and  target  radar  capabilities  all  form  inputs  to  determine  this  first-cut  route. 
A  time  correlation  is  then  achieved  to  synchronize  the  mission  with  the  oper¬ 
ating  times  of  the  emitter  (if  these  are  known).  The  planner  adjusts  the  flight 
route  to  achieve  maximum  probability  of  detection  based  on  signal  up-time 
and  duration.  Further,  the  ELINT  planners  also  consider  techniques  to 
entice  an  emitter  into  operation  so  that  the  signal  can  be  detected  and  recorded 
without  jeopardizing  mission  safety  (i.  e. ,  "spoofing"  the  emitter  by  deploying 
deception  drones  which  simulate  strike  vehicles). 

Upon  completing  the  ELINT  planning  cycle,  the  planner  begins  a  threat  anal¬ 
ysis  process  to  minimize  vulnerability.  The  threat  analysis  process,  and 
the  analysis  of  fuel  requirements,  are  almost  identical  in  procedure  to 
Strike  mission  planning.  ELINT  missions  would  be  checked  against  other 
missions  with  which  they  are  coordinated  through  the  Time  Sequence  Review. 

A  flow  diagram  of  the  planning  process  is  shown  in  Figure  4.4-1. 
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Figure  4.4-1.  Major  Steps  of  tile  ELINT  Mission  Planner  Process 
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SECTION  5 


ADP  SUPPORT  TO  RPV  COMMAND  AND  CONTROL  FUNCTIONS 


5.1  INTRODUCTION 


The  Command  and  Control  functions  that  must  be  implemented  to  plan  and 
execute  RPV  operations  were  described  in  Section  3  and  the  requirements 
for  ADP  support  were  addressed  for  each  function.  Where  ADP  support 
was  required,  specific  implementation  concepts  and  procedures  were  des¬ 
cribed.  Where  applicable,  ADP  Support  was  based  on  the  Mission  Planner 
Breadboard  System  implementation.  In  Section  3  the  emphasis  was  on 
those  functions  most  affected  by  the  unique  characteristics  of  RPV.  Section 
4  described  the  Mission  Planner  Breadboard  System  emphasizing  its  appli¬ 
cation  to  RPV  Command  and  Control.  Functions  not  specifically  identified 
in  Section  3,  which  have  been  implemented  in  the  MPBS  and  are  applicable 
to  any  air  operation  are  included,  such  as,  resource  management  and  TAGS 
assignments. 

This  section  integrates  the  ADP  support  requirements  which  have  been  identified 
and  develops  data  on  the  performance  parameters  for  the  elements  of  the 
ground  based  RPV  Command  and  Control  ADP  Support  Database  and  Software. 

5.2  APPLICATION  PROGRAM  REQUIREMENTS 

Table  V.2-1  3nd  Table  V.2-2  tabulate  the  application  programs  that  support 
RPV  Command  and  Control  in  Physical  Control  and  Mission  Planning  re¬ 
spectively.  Column  1  identifies  each  applications  program  by  a  short  title 
with  brief  description  of  the  program.  Column  2  references  the  section  of 
this  report  where  the  program  performance  is  described.  Generally  the 
referenced  text  describes  the  program  in  terms  of  why  ADP  support  is  re¬ 
quired  and  how  the  required  support  can  be  implemented. 

The  programs  as  listed  provide  several  levels  of  automated  support.  Cer¬ 
tain  programs  are  required  in  all  employment  situations;  other  programs 
are  optional  and  may  not  be  required  to  provide  effective  planning  and 
rapid  response  for  small  force  operations.  This  section  considers  ADP 
independent  of  the  frequency  or  employment  situation.  The  relative  im¬ 
portance  of  various  elements  of  ADP  support  to  RPV  Command  and  Control 
is  addressed  in  Section  6. 

Table  V.2-3  tabulates  the  estimates  on  the  size  of  the  application  program 
the  values  expressed  as  thousands  of  instruction  codes  (Column  2) 
conform  to  the  usual  conversion  for  expressing  the  size  of  an  application 
program.  An  entry  in  Column  3  applies  to  certain  programs  where  program 
logic  is  included  in  a  program  data  base.  Column  4  identifies  the  opera¬ 
tional  data  files  which  are  accessed  when  the  program  is  called. 
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Preference 


3.2,4.  RPV  Status  Re¬ 
ports  A  capability  sub¬ 
sumed  in  many  sections 


The  final  column  identifies  the  basis  for  the  estimates.  Where  the  refer¬ 
ence  is  to  Section  3  of  this  report,  the  referenced  section  describes  the  pro¬ 
gram  and  its  application.  When  a  program  description  only  is  provided,  the 
estimated  size  is  based  on  engineering  judgement  and  analogy  to  MPBS  pro¬ 
grams  that  provide  a  similar  type  of  processing  capability.  Where  the 
reference  is  to  MPBS,  the  program  for  RPV  applications  is  the  same  as, 
or  a  slight  modification  of,  the  MPBS  program  implementation. 

Table  V.2-1  Application  Programs:  Physical  Control  Of  RPVs 


Identification  and  Description 


Navigation  Position:  This  receives  LORAN 
signal  data,  and  extablishes  the  RPV  position 


Message  Processing:  This  processes  input 
me9sages~'and  provides  legality  and  validity 
checks,  routine  logic,  and  composes  and 
addresses  output  messages. 


Flight  Control  Enroute:  This  is  established 


from  planned  Flight  Profile  Position  Loca¬ 
tion  Planned;  Compare  to  Actual.  Flight 
Control  Adjustemnt  required  is  calculated, 
and  if  any,  control  directive  and  Output  to 
FPV,  or  to  Operator,  is  prepared. 


Antenna  Pointing  Angle:  This  maintains  data 


on  communications  contacts  with  each  RPV. 
If  contact  is  not  made  within  a  preset  time 
period,  it  establishes  from  the  Plan  the 
planned  location  for  the  RPV,  obtains  data 
or  Relay  A/C  location,  and  calculates  the 
pointing  angle. 


RPV  Position  for 


Target  vidwo  priority  with  EO  symbol 
positions  is  displayed  on  video.  Weapon 
boresight  position  is  established  on  the 
video  picture,  and  weapon  bora sight  is 
positioned  or.  «id«,o.  This  usee  petition 
data,  v«tMctty  data,  and  EO  situor  ancles 
reported,  applying  smoothing  and  pre¬ 
dictin'!  to  update. 


Weapon  Release  Envelope :  This  determines 


U  ihe  RPV  flight  path  is  within  the  Weapon 
Release  envelope.  It  inhibits  the  weapon 
release  envelope,  and  inhibits  weapon  re- 
s  lease  if  not  in  envelope 

V  -»  Kuma’iw,-  «i  i  m******  i«m.>  ««.■■■  i  ■  »■-  «  —  .«.«  i  — fc. 


Table  V.  2-2  Application  Programs:  RPV  Mission  Planning 


Identification  and  Description  j  Reference 


Route  Profile  Coding:  This  is  a  route  pro-  3.3.2 

file  specified  in  terms  of  flight  profile  seg¬ 
ments  identified  as  standardized  flight  mode 
{e.g.  launch)  and  legs  specified  in  terms  of 
end-point  positions,  altitude,  power  mode 
and  climb,  decend,  or  cruise.  The  output 
is  a  set  of  coded  flight  control  instructions. 


Semi  Automatic  Route  Planning:  Thi s  d:. s - 
plays  the  mission  geometry  and  threat  data, 
The  capability  to  use  preplanned  routes,  and/ 
or  historical  routes  is  provided.  The  opera¬ 
tor  may  create  or  modify  any  route.  Auto¬ 
matic  checks  are  provided. 


Automatic  Route  Selection:  Using  precoded 
throat  data,  the  process  finds  three  lowest 
threat  routes  through  a  defended  area  and 
a  lowest  threat  route  that  overilys  an  oper¬ 
ation  designated  IP. 


Ruute  Safety  Scoring:  Using  a  given  route 
profile  the  function  scores  the  route  expres¬ 
sing  route  safety  in  terms  of  accumulated 
time  within  threat  zones  weighted  by  the  type 
of  threat.  The  process  accumulates  scores 
by  route  leg  and  over  the  total  route.  Al¬ 
ternate  routes  may  be  compared. 


Automatic  Route  Adjustment:  Using  a  route 
profile  which  is  input  (grossly  defined),  the 
system  creates  additional  route  segments, 
such  that  the  adjusted  route  avoids  or  en- 
route  threats  or  minimizes  the  threats. 


RPV  Communications  Line  of  Sight  Masking: 
In  the  route  profile  planning  process,  this 
program  obtains  prestored  data  on  LOS 
masking  to  a  predetermined  relay  aircraft 
flight  profile  from  the  data  base. 


4.1.2 


3.  3.2.  3 
4,1.2 


3.  3.2.3 
4.1.2 


3.  3  .  2?  4 


3.  3.4.3 


Table  V.2-2  Application  Programs:  RPV  Mission  Planning  (continued) 


Identification  and  Description 

Reference 

Relav  Aircraft  Flight  Profile  Planning: 

3. 3. 4. 1  through 

Using  data  generated  by  the  RPV  communi¬ 
cations  LOS  Masking  program,  the  program 
plans  a  Relay  A/C  flight  profile  and  schedule 
such  that  over  time  the  relay  aircraft  is 
positioned  to  satisfy  operational  requirements 
for  LOS  communications  and  to  minimize  the 
possibility  of  jamming  in  an  intense  jamming 
environment. 

3. 3. 4. 5 

Relav  Aircraft  Flight  Profile  Planning  to 

3.  3.  5.  3.  3 

Avoid  Jamming  by  Specific  Jammers:  Using 
data  on  known  jamming  sites,  the  program 
calculates  the  communications  jam  to  signal 
ratio  for  several  relay  aircraft  positions. 

The  data  is  displayed  and  the  operator  sel¬ 
ects  the  desired  position. 

4.1.2 

Weapon  Selection:  Using  precoded  weapon 
effects  data  from  the  Joint  Munitions  Effect¬ 
iveness  Manual,  the  program  displays  data 
on  the  three  best  weapons  (ordnance,  carrier, 
and  delivery  tactic)  against  the  target  type.  It 
calculates  a  probability  of  excess  Ps  if  number 
of  A/C  or  RPV's  are  input,  or  number  of  A/C 
or  RPV's  required  if  desired  Ps  is  input 

3.3.7 

4.1.2 

ECM  Mission  Flanning:  This  program  cal- 

3. 3. 9. 2 

culates  the  jam  to  signal  ratio  using  mission 
geometry,  radar  cross  section  data,  and 
technical  data  of  emitters  and  receivers. 

4.1.  2 

Chaff  Precursor  Mission  Planning:  This  pro- 

3.  3. 9.  3 

gram  generates  a  mission  profile  for  a  chaff 
precursor  mission  using  mission  geometry 
data,  technical  data  on  chaff  packages,  and 
data  on  variables  effecting  chaff  dispersion 
such  as  atmospheric  winds. 

Target  Review:  This  program  displays  data 
on  the  target  against  which  the  mission  is 
being  planned  and  other  data  supporting  the 
planning  process. 

4.1.2 
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Table  V.2-2  Application  Programs:  Physical  Control  Of  RPVs  (continued) 


Identification  and  Description 


Reference 


Plan  Review:  With  data  based  on  planned  flight 
profiles,  this  program  generates  and  displays 
tracks  at  rates  many  times  real  time,  exam¬ 
ines  plans  'or  airspace  conflicts  and  facility, 
and  operator  overloads. 


3.3.10 

4.2.1 

4.3 


5.3  DATA  BASE  AND  PROCESSING  RATES 

The  principal  operational  data  which  must  be  in  the  data  base  for  physical 
control  are  the  coded  mission  profiles  generated  by  the  planning  function. 
TheBe  data  are  estimated  to  require  188K  bytes  of  storage  for  240  missions 
(Ref.  Subsection  3.  3.2.5).  Message  formats  and  address  and  routing 
tables  may  require  another  100  K  bytes  of  storage.  The  six  application 
programs  required  for  physical  control  are  relatively  small,  totaling 
3.6  KI's,  The  first  three  programs  listed  above  in  Table  V.2-1  total  3.2  KI1 
and  are  executed  periodically  each  half-second.  The  antenna  pointing  angle 
program  is  executed  as  required  when  the  relay  aircraft  has  lost  communi¬ 
cations  contact  with  an  RPV  mission.  The  two  over-the -target  programs 
are  executed  each  0.2  second.  Based  on  these  programs  and  these  exe¬ 
cution  rates,  it  can  be  estimated  that  the  processing  required  to  execute 
the  application  programs  for  physical  control  are  approximately  7  KIPS  for 
enroute  control,  and  one  to  two  KIPS  for  over-the-targat  control.  These 
estimates  do  not  include  the  processing  required  to  service  operator 
initiated  requests  for  data  nor  the  processing  required  to  generate  and  main¬ 
tain  displays.  Based  on  TACC  and  SEEK  FLEX  simulations  of  the  TACC 
Current  Operations  Functions,  the  processing  required  to  service  operator 
requests  and  provide  operator  displays  are  under  5KIPS  on  the  average. 

The  conclusion  is  that  the  processing  rates  for  physical  control  are  not  high. 
An  ADP  system  in  the  50  to  100  Kilo  instructions  per  second  (KIPS)  range  is 
indicated. 

For  force  planning,  the  operational  data  base  is  large.  Quantitative  esti¬ 
mates  can  be  developed  at  the  function  level  recognizing  the  similarity  in  the 
data  base  required  for  planning  RPV  missions,  to  that  required  to  planned 
manned  aircraft  missions.  Thus  it  is  possible  to  estimate  probable  total 
data  ba* e  requirements.  Under  the  SEEK  FLEX  study,  it  was  estimated 
that  to  plan  and  monitor  combat  and  combat  support  missions  (airlift  mis¬ 
sions  excluded)  an  operational  data  base  of  about  one  million  bytes  was  re¬ 
quired.  The  MPS  data  base  for  the  Advanced  Development  Mission  Planner 
System  has  been  estimated  at  7.2  million  bytes.  In  ADMPS  two  files,  pre¬ 
scored  automatic  route  selection  tables  and  terrain  masks,  account  for  3.6 
million  bytes  in  the  7,2  million  total.  Another  million  bytes  relate  to  wea¬ 
pon  selection  and  A/C  configuration;  0.5  million  bytes  are  unique  to  ECM 


1000  instructions 


Table  V.  2-3  Application  Programs,  RPV  Command  &  Control  (continued) 


Review  16,5  Coded  RPV 

Mission  Flight  Profile 


and  route  safety  scoring.  Considering  these  data  base  totals  in  the  light 
of  specific  requirements  to  plan  RPV  missions,  an  operational  data  base 
in  the  order  of  4  to  6  million  bytes  appears  required  to  implement  ail 
algorithms  for  RPV  mission  planning.  Data  base  usage  factors  are  such 
that  core  storage  requirements  are  not  excessive. 

The  application  programs  supporting  mission  planning  and  force  monitoring 
and  replanning  are  estimated  to  require  162,6  KI's.  These  programs  are 
operator  initiated  or  are  called  by  operator  initiated  programs.  The  pro¬ 
cessor  requirements  expressed  in  KIPS  which  are  needed  to  execute  these 
programs  depends  upon  many  factors.  Two  dominating  factors  are;  1)  the 
number  of  operators  simultaneously  planning  and  replanning  missions,  and 
2)  the  degree  to  which  the  operators  request  amplifying  data.  This  latter 
factor  determines  the  rate  at  which  application  programs  are  called  which  in 
turn  influences  processor  requirements  since  applications  programs  use 
more  processor  time  than  the  review  of  amplifying  data.  Based  on  the 
similarity  between  mission  planning  and  monitoring  for  RPV  and  for  manned 
missions,  plus  experience  gained  from  MPBS,  the  processing  rates  re¬ 
quired  for  the  RPV  force  planning  and  monitoring  system  are  on  the  order 
of  100  to  300  KIPS,  depending  in  part  on  how  frequently  the  operators  choose 
to  call  programs  like  terrain  masking  and  automatic  route  selection. 

5.4  OPERATING  SYSTEM  CONSIDERATIONS 

5.4.1  DCF  Multiple  RPV  Control  Element 

A  resident  executive  function  is  required  to;  1)  support  the  control  of  20 
drone  subscribers,  2)  provide  operator  communications  (considering  graph¬ 
ical  and  tabular  displays),  and  3)  provide  system  scheduling  and  core  al¬ 
location  for  limited  real  time  environment. 

An  additional  requirement  exists  for;  1)  interrupt  handlers  and  the  main 
memory  ro^p,  and  2)  I/O  control  and  handlers, 

A  non'-resident  O/S  portion  including  infrequently  used  operator  communi¬ 
cation’  functions  such  as  keyboard  processing,  report  generation,  and  sys¬ 
tem  functions  such  as  device  and  resource  allocations  is  allocated  to  a  pri¬ 
mal/  mass  storage  device.  These  functions  can  be  swapped  in  and  out  of 
main  memory  as  required.  In  addition,  with  a  limited  main  core  capacity, 
applications  programs  and  data  could  be  allocated  on  the  external  device 
and  be  swapped  in  the  same  manner. 

5.4.2  DCF  Weapon  Delivery  Control  Element 

The  requirement  to  provide  Video  Display  control  is  included  in  the  estimate 
for  the  non-resident  O/S  system  function  for  the  DCF  Basic  Control  element. 
This  control  function  is  allocated  in  this  manner  considering  the  co-location 
of  the  two  elements . 


DCF  Force  Planning  Air  Monitoring  Element 

Considering  the  optimizing  of  throughput  and  response  requirements  in  an 
interactive  real  time  environment,  a  resident  O/S  estimated  at  approx¬ 
imately  75,000  bytes  is  required.  Dynamic  core  and  device  allocation, 
diagnostic  error  processing,  program  loading,  and  interactive  operator 
communication  functions  are  considered. 

Table  V.4-1  indicates  the  estimated  (in  bytes)  size  of  O/S  functions  allo¬ 
cated  for  each  element. 


Table  V.4-1  Estimated  O/S  Functions 


System  Tasks 

DCF  Planning 

DCF  Multiple  RPV 

Control  Element 

Element 

Resident  Exec 

Scheduling 

400 

400 

400 

Core  Allocation 

4,  000 

800 

800 

Device  Allocation 

800 

400 

400  * 

Resource  Allocation 

1.  200 

400 

400* 

Program  Loads 

4,000 

Swapping  Control 

3,  600 

Task  Dispatching 

200 

Interrupt  Handler 

800 

mSm 

800** 

Program  Terminator 

4,000 

1 

1,000 

Abnormal  End  Term, 

800 

400 

400 

Generator  Common. 

24,000 

12,000 

1,  600 

Restart 

4,  000 

4,000 

1,600 

Diagnostic  Error  Prc. 

4.  000 

1,200 

1,200 

Timers 

200 

200 

200** 

Program  Control  Trace 

400 

Memory  Map 

10, 000 

7,000 

7,  000 

I/O  Control  Program 

10,000 

8,  000 

6,000* 

I/O  Device  Handler 

2,400 

TOTAL 

74, 800 

39.  200 

23,400 

*  Resident  in  I/O  control  region 
**  Resident  in  memory  map  region 
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SECTION  6 


RPV  COMMAND  AND  CONTROL  SYSTEM  CONCEPTS 


6. 1  INTRODUCTION 

Litton' s  analysis  of  the  RPV  command  and  control  system  requirements  is 
documented  in  Section  3.  In  the  analysis  three  components  of  the  RPV  Sys¬ 
tem;  1)  the  RPV  vehicle,  2)  the  relay  aircraft,  and  3)  the  Command  and  Con¬ 
trol  element(s)  were  addressed.  The  analysis,  however,  centered  on  the 
command  and  control  elements  and  the  requirements  to  provide  effective 
Command  and  Control  of  RPV  operations,  e.g. ,  requirements  to  plan  the 
missions,  to  execute  operations  as  planned,  and  to  adjust  operations  as 
required. 


Command  and  Control  procedures  and  implementation  concepts  were  designed 
to  provide  effective  Command  and  Control  while  concurrently  minimizing  the 
RPV  vehicle  on-board  avionics  and  the  communication  required  to  maintain 
control  of  the  airborne  RPVs. 

Command  and  Control  requirements  group  into  three  functional  areas  which 
are  separable  in  terms  of  operator  skill,  automated  data  processing  and  dis¬ 
play  support,  and  communications  requirements.  These  three  functional 
areas  are: 

a.  RPV  Mission  Planning  and  Force  Control. 

b.  Control  of  the  RPV  inflight  from  launch  to  recovery  except  for 
close  control  of  the  strike  RPV  vehicle  in  the  weapon  delivery 
phase. 

c.  Control  of  the  strike  RPV  during  weapon  delivery  and  bomb 
damage  assessment. 

Figure  6.1-1,  RPV  System  Elements,  depicts  in  specification  tree  format 
the  elements  of  the  RPV  system  which  have  been  addressed  in  this  study  (bold 
outline)  and  other  essential  system  elements  which  have  been  subsumed.  The 
dashed  boxes  are  elements  that  are  or  may  be  external  to  the  RPV  system. 
This  section  addresses  specifically  the  system  performance  parameters  for 
the  RPV  Command  and  Control  Elements  of  the  system.  Alternative  system 
configuration  for  the  Command  and  Control  elements  are  developed,  and  the 
advantages  and  disadvantages  of  each  are  addressed.  A  preferred  system 
configuration  is  selected,  and  alternatives  to  the  preferred  configuration  are 
then  presented. 

6. 2  SYSTEM  CONCEPT 


Functional  areas  for  RPV  Command  and  Control  are  identified  as  follows: 
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RVP SPEC  TREE 


DCF,  Multiple  RPV  Control  Element:  The  functional  area  included  in  this 
element  is  the  physical  control  of  RPV  from  launch  to  recovery  using  status 
data  reported  by  the  RPV  and  position  data  provided  by  the  navigation  subsys¬ 
tem.  This  functional  area  provides  the  physical  control  required  for  RPV 
operations,  excepting  over-the-target  control  of  RPV  strike  missions.  For 
brevity,  such  control  is  referred  to  as  the  DCF,  Multiple  RPV  Control 
Element. 

DCF,  Weapon  Delivery  Control  Element!  The  functional  area  included  in 
this  element  is  the  physical  control  of  RPV  using  status  data  reported  and 
more  precise  position  data  which  are  developed  from  imagery  data  obtained 
from  RPV  EO  Sensor  Subsystem.  This  functional  area  provides  control  of 
the  RPV  strike  mission  in  the  weapon  delivery  phase  and  for  bomb  damage 
assessment.  For  brevity,  such  control  is  referred  to  as  the  DCF,  Weapon 
Delivery  Control  Element. 

DCF  Planning  and  Force  Monitoring  Element:  The  functional  area  included 
in  this  element  is  the  RPV  planning  function,  mission  replanning,  and  adjust¬ 
ment.  For  brevity,  such  control  is  referred  to  in  this  section  as  the  DCF 
Planning  Element. 

The  distinctive  features  of  each  of  these  elements  are: 

DCF,  Multiple  RPV  Control  Element  Features:  The  requirements  for  pro¬ 
cessing  support  are  characterized  by  a  system  that  operates  principally  on 
data  provided  by  the  Communications  System.  From  the  RPV,  the  element 
obtains  data  that  are  used  to  establish  die  location  of  the  RPV  from  launch 
to  recovery.  Data  on  the  status  of  the  RPV  are  obtained.  The  reported 
condition  is  compared  to  the  condition  that  should  exist  according  to  plan. 
Deviations  are  detected  and  appropriate  control  directives  are  formulated 
and  transmitted  to  the  RPV,  From  the  planning  element,  directives  may  be 
received  to  redirect  missions.  Control  directives  are  formulated  and  trans¬ 
mitted  to  the  RPV  inflight,  or  to  the  launch  control  facility,  for  missions  not 
yet  launched. 

The  principal  operational  data  required  are  data  on  the  plans  for  the  RPV 
missions  as  generated  by  the  planning  function.  Activity  is  generated  in 
near  real  time  by  data  received  from  the  Communications  System.  Emer¬ 
gency  conditions  excepted,  response  time  requirements  are  not  immediate; 
that  is,  within  fractions  of  minutes.  Communications  rates  are  relatively 
low. 

DCF,  Weapon  Delivery  Control  Element  Features:  In  contrast  to  the  DCF 
Multiple  RPV  Control  Element,  the  Weapon  Delivery  Control  Element  is 
characterized  by  near  real  time  requirements  for  communications,  process¬ 
ing  support,  and  operator  actions.  Imagery  data  from  the  RPV  must  be 
communicated,  processed,  and  displayed.  Near  real  time  reporting  and 
processing  of  RPV  status  data  are  required  to  provide  the  capability  for 
manual  control.  Full  time  operator  action  is  required.  Communications 
rates  arc  relatively  high. 
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DCF  Planning  and  Force  Monitoring  Element  Features:  The  distinctive  char¬ 
acter  of  the  planning  element  relates  to  the  ADP  support  required.  A  rela¬ 
tively  large  operational  data  base  is  required  (friendly  force  status,  enemy 
order  of  battle,  geophysical  data,  commanders  guidance,  and  planning  fac¬ 
tors).  ADP  Support  is  also  characterized  by  relatively  large  applications 
programs  required  to  support  the  planning  functions.  For  preplanning, 
rapid  response  is  not  an  absolute  requirement.  However,  since  the  ADP 
System  interacts  with  the  operator  and  the  throughput  requirements  are  rela¬ 
tively  high,  the  ADP  System  must  be  capable  of  responding  to  operator 
requests  for  processing  in  a  few  seconds.  To  satisfy  response  time  require¬ 
ments  for  mission  replanning,  a  rapid  response  is  required.  The  ADP  Sys¬ 
tem  must  be  capable  of  simultaneously  supporting  multiple  operators  planning 
different  types  of  missions.  The  communications  requirements  are  relatively 
low. 

6.3  SYSTEM  SYNTHESIS 
6.3.1  Introduction 

The  subsections  that  follow  synthesize  the  system  requirements  of  the  system 
elements  that  have  been  identified  and  described  in  die  preceding  sections. 

The  system  requirements  are  expressed  in  terms  of: 

o  Communications  interface  requirements. 

o  ADP  support  requirement#, 

o  Operator  and  operator  facility  requirements. 

Maintenance  support  requirements  are  not  included. 

The  quantitative  factors  presented  are  based  on  Sections  3  and  4  as  developed 
and  summarized  in  Section  5,  ADP  Support  Requirements. 


6.3.2  DCF,  Multiple  RPV  Control  Element 


Communications  Interfaces:  The  principal  interface  is  with  the  airborne  RPV. 
The'  data'  pr  es  enteci  "in  this  "section  assumes  all  communications  to  the  RPV' 
inflight  are  through  the  relay  aircraft.  This  maximizes  the  requirements  on 
the  most  critical  interface  links  in  the  RPV  system.  Any  direct  communica¬ 
tions  between  the  DCF  and  airborne  RPV,  within  line  of  sight  communications 
range  of  the  DCF,  would  merely  reduce  the  link  requirements  to  the  relay 
aircraft  without  concurrently  imposing  other  critical  system  requirements. 


Other  interfaces  are  with  launch  and  recovery  operations  and  with  the  DCF 
planning  element.  It  is  an  operational  assumption  that  interlaces  with  the 
TAGS  and  other  external  system  elements  will  be  through  the  DCF,  RPV 
Mission  Planning  and  Force  Control  Element.  Tabic  VI.  3-1,  DCF,  Multiple 
RPV  Control  Element  Communications  Interfaces,  tabulates  quantitative  data 
on  these  interfaces.  Column  1  is  the  interfacing  element,  Column  2  the  type 
data  exchanged,  (1)  signifies  input  to  the  DCF,  Basic  Control  Element, 
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Table  VL3-1.  DCF  Multiple  RPV  Control  Element  Communications  Interfaces 
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(O)  an  output.  (I/O)  signifies  a  message  exchange,  e  g. ,  inputs  generating 
outputs,  and  vice  versa.  The  right-hand  column  is  the  reference  to  the  sub¬ 
section  in  the  study  report  where  the  quantitative  factors  on  message  rate 
and  message  length  are  addressed.  The  entry  485L  means  the  data  were  ob¬ 
tained  by  analogy  to  the  485 L  System  and  are  derived  from  the  485  L  System 
Specification.  The  entry  (EJ),  signifies  an  "engineering  judgment"  factor  not 
specifically  addressed  in  the  study.  The  message  length  and  the  bit  rates  cal¬ 
culated  in  Columns  4,  5,  and  6  are  information  bits  only. 

Further  discussion  of  the  three  basic  data  links  illustrated  in  Table  VI.  3-1 
are  described  in  paragraphs  a. ,  b. ,  and  c.  below. 

a.  DCF/ Launch  Site  and  DCF/Recovery  Site  Link:  The  average  bit 
rates  are  not  calculated.  The  link  must  be  available  on  demand. 
It  is  assumed  that  at  any  launch  site  there  can  be  only  one  launch; 
similarly,  at  the  recovery  site,  only  one  recovery.  A  low  data 
rate  link,  e.g.  600  BPS,  two  way  simplex,  satisfies  all  re¬ 
quirements, 

b.  DCF  RPV  Command  Response  Link  via  Relay  Aircraft:  Total 
bit  rates  tabulated,  information  bits  only,  are  10?  BPS  incom¬ 
ing  to  the  DCF,  eight  BPS  outgoing.  These  rates  apply  to  the 
DCF  to  Relay  Aircraft  Link  with  20  RPVs  under  control.  The 
Relay  A/C  to  individual  RPVs  rate  is  one-twentieth  of  this,  5 
BPS  RPV-to-Relay  A/C,  0.4  BPS  to  the  RPV.  These  data  are 
meaningful  only  to  highlight  that  the  average  information  rate 
that  must  be  sustained  is  low.  There  are  several  factors  which 
now  must  be  considered.  There  are  occasional  longer  messages 
to  and  from  individual  RPVs.  The  system  must  be  capable  of 
accommodating  such  transient  peaks.  Individual  RPV  may  be 
serviced  in  turn.  The  overhead  requirements  of  addressing  and 
synchronisation  must  be  satisfied  and  error  control  must  be  ac¬ 
complished.  Quantitative  factors  for  these  functions  cannot  be 
established  without  postulating  specific  link  characteristics,  the 
scanning  method,  and  a  signal  structure. 

However,  given  that;  1)  the  average  information  data  exchange 
rates  are  low,  2)  that  exceptions  requiring  rapid  response  are 
RPV-initiated  and  that  simultaneous  exceptions  are  unlikely, 
and  3)  that  certain  longer  messages  can  be  chained  over  several 
contacts;  there  are  methods  of  implementation  that  can  result  in 
relatively  low  overhead  rates.  Using  a  synchronising  signal  and 
time  slot  addressing,  on  the  order  of  200  bits  per  sector  scan 
are  indicated.  A  factor  of  two  on  the  information  bits  returned 
for  redundancy  is  indicated.  Assuming  20  sectors  scanned  to 
contact  20  RPVs,  such  methods  yield  link  capacities  like  200 
bits  per  contact  on  the  dawn  link  (to  the  RPV).  On  the  up  link, 

150  bits  provides  a  capability  to  transmit  larger  messages  if 
messages  can  be  chained.  With  contact  intervals  like  0.  5  sec¬ 
onds  (wRh  20  RPVs,  10  second  contact  interval  for  each  RPV), 
a  600  BPS  full  duplex  data  link  is  indicated  from  the  RPV  to  the 
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relay  aircraft.  Similar  engineering  judgment  factors  yield  the 
conclusion,  that  the  DCF  to  Relay  A/C  link  should  also  be  in  the 
order  of  600  BPS  (the  information  data  rate  is  10?  BPS  on  th«- 
down  link, )  If  the  DFC -to -Relay  A/C  Link  has  the  same  char¬ 
acteristics  as  the  Relay  A/C-tc-RPV  Link,  direct  communica¬ 
tions  between  the  DCF  and  the  RPV  can  be  implemented  through 
assignin',  it  procedures  applying  the  same  method  as  used  to 
assign  an  RPV  mission  to  one  or  another  relay  aircraft. 

c .  DCF,  Multiple  RPV  Control  Element/DCF  Planning  and  Force 
Monitoring  Element;  Considerations  on  this  link  are  that  the 
sustained  data  rates  are  relatively  low.  Relatively  long  mes¬ 
sages  are  occasionally  transmitted.  Communications  are  re¬ 
quired  on  demand.  If  these  two  elements  are  co-located,  this 
interface  is  internal  to  the  data  processing  system.  If  remoted, 
a  link  like  600  BPS  appears  adequate  (on  a  600  BPS  link,  a  65 
segment  route  profile  could  be  transmitted  in  16  seconds). 

d.  DCF,  Weapon  Delivery  Control  Element;  The  fact  that  Weapon 
Delivery  Control  Element  has  been  defined  to  be  separable  from 
the  DCF,  Multiple  RPV  Control  Element  dictates  an  interface 
requirement  between  the  two  elements,  A  system  assumption 
is,  however,  that  these  two  elements  are  colocated  and  inte¬ 
grated  into  a  single  ADP  Support  system.  The  interface  is 
therefore  internal  to  the  ADP  system.  The  requirement  is  to 
provio  -  a  console- to-console  interface,  a  capability  usually 
provided  in  a  multi- operator  system  of  the  type  being 
considered, 

ADP  Support  Raqui foments;  The  ADP  Support  requirement*  for  the  Multiple 
RPV  Control,  developed  in  section  V  are; 

Data  Base  Required,  Approximately  16 IK  bytes,  one 

RPV  unit  of  £6  vehicles,  2K8K 
bytes,  Cor  a  3  unit  force. 

Application  Program*)  4,8  KU  (include  1,  3  Kls  for 

Flight  Profile  coding). 

Operating  System;  3'4 .  Z i\  bytea. 

Operator,  Operator  PacliHi-sr  The  physical  control  procedures  that  have 
been  postulated  require  a«  operator  console  providing  simultaneous  graphic 
and  tabular  displays.  This  may  be  a  dual  display,  or  a  split  screen  approach 
may  be  used.  Con  ache  control  requirements  are  those  typical  of  Control 
Consoles  such  5$  specified  for  the  485 L  System,  The  number  of  consoles 
required  depend  upon  the  number  of  operators  required  which,  in  turn,  de¬ 
pends  upon  aperMqr  l«?£dltv§.  Table  VI,  3-2,  DCF,  Multiple  RPV  Control 
Element.  Ope?a.for  Lo.*ida>  tabulates  operator  load  factors.  Based  on  the 
factors  a#?un\ed,  total  operator  time  per  mission  is  just  over  three  minutes. 
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Table  VI.  3-2„  DCF,  Multiple  RPV  Control  Element,  Operator  Loads 


Controller 


Total  operator  time  for  controlling  20  missions  simultaneously  for  a  full 
hour  is  71.3  minutes.  Considering  that  this  is  the  load  for  a  peak  activity 
period,  and  that  many  of  the  operator  actions  can  be  delayed  minutes  without 
any  loss  in  effectiveness,  it  is  judged  that  two  operators  can  provide  the  re¬ 
quired  control.  There  is,  however,  a  requirement  for  a  third  operator  to 
monitor  the  operation  of  the  unit's  force.  Additionally,  third  operator  sta¬ 
tion  provides  capability  to  handle  transmit  peak  loads  and  a  backup  capability 
to  maintain  control,  should  one  operator  station  fail.  Therefore,  three 
operator  stations  are  proposed. 

6.3.3  DCF,  Weapon  Delivery  Control  Element 

Communications  Interfaces:  The  requirement  to  interface  with  the  DCF, 
Multiple  RPV,  Control  Element  was  included  in  the  preceding  subsection. 

The  only  other  interface,  and  the  significrnt  one,  is  with  the  RPV  through 
the  relay  aircraft.  Table  VI.  3,-3  tabulates  the  quantitative  data. 

The  electro  optical  video  data  is  characterized  by  a  requirement  to  transmit 
from  each  RPV  to  the  DCF  high  resolution  video  data  in  near  real  time.  A 
high  data-rate  broad-band  link  is  thus  inherent  in  the  requirement  to  control 
several  RPVs. 

Data  on  the  control  directives,  DCF-to-RPV,  are  extracted  from  Table  III. 2-1  . 
The  messages  identified  as  aperiodic  are  principly  once  per  mission  mes¬ 
sages  which  initiate  and  terminate  the  weapon  delivery  phase.  The  principal 
exception  is  the  sensor  zoom  message.  The  BPS  estimate  is  therefore  the 
bit  rate  established  by  the  requirement  to  report  at  0.2  second  intervals  with 
the  sensor  zoom  message  superimposed  on  every  message.  The  RPV  to  DCF 
data  rates  are  dominated  by  the  periodic  messages  that  generate  261  BPS. 

Given  that  there  is  a  broad  band  link  established  from  the  RPV  to  the  DCF 
through  the  relay  aircraft,  the  data  rates  are  low  .  elative  to  the  data  re¬ 
quired  to  transmit  the  video.  It  is  assumed  that  the  link  is  implemented 
using  the  same  antennae  used  for  the  video  link  with  the  digital  data  multi¬ 
plexed  on  the  video  on  the  up  link.  The  down  link,  relay  aircraft  to  RPV, 
will  be  implemented  by  routing  the  message  to  the  Relay  Aircraft  Video  link 
antenna. 

Since  the  system  requirement  is  to  control  four  RPV  over -the -target  simul¬ 
taneously,  the  link  requirements,  DCF  to  relay  aircraft,  are  four  times  the 
numbers  on  the  table;  that  is,  approximately  1,000  BPS  from  the  Relay  A/C 
to  DCF  and  1,600  3PS  on  the  up-link  from  the  DCF  to  the  relay  aircraft. 
Considering  that  these  rates  are  sustained  on  dedicated  links,  link  capaci¬ 
ties  of  2,400  BPS  minimum  are  indicated. 

ADP  Support  Requirements:  The  ADP  Support  for  Weapon  Delivery  Control 
developed  in  Section  o  presupposed  that  the  Weapon  Delivery  Control  element 
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is  colocated  with  a  DCF  Multiple  RPV  Control  element.  Given  this,  the  addi¬ 
tional  ADP  support  required  is: 

Data  Base:  Not  significant 

Applications  Programs:  0.  3  KIo 

Operating  System:  Common  with  the  DCF  Multiple  RPV  Con¬ 

trol  Element.  Additional  video  display 
control  requirements  are  estimated  2  to 
4K  bytes. 

These  estimates  do  not  include: 

a.  The  Data  base  required  to  store  historical  video  on  the  target 
nor  the  processing  required  to  display  historical  video  concur¬ 
rently  with  the  real  time  video  picture. 

b.  Processing  required  to  calculate,  at  the  DCF,  a  weapon  release 
point  for  "dumb  bombs"  and  to  transmit  a  release  directive  to 
the  strike  RPV. 

Operator  Facilities  and  Operator  Requirements:  The  console  display  require¬ 
ment  for  weapon  delivery  is  to  display  the  EO  Sensor  video  picture  with  que- 
ing  symbols  superimposed.  An  additional  capability  to  concurrently  display 
queing  video,  is  desirable.  Some  type  of  cursor  control  for  steering  the  EO 
sensor  is  required.  Other  controls  to  couple  EO  sensor  steering  to  the  RPV, 
to  enable  or  direct  weapon  release  and/or  to  initiate  the  escape  maneuver, 
reattack,  divert,  or  return  to  base  are  required.  Since  implementation  is 
based  on  continual  operator  control  in  the  weapon  delivery  phase,  an  opera¬ 
tor  and  an  operator  console  is  required  for  each  target  simultaneously  en¬ 
gaged.  With  four  simultaneous  attacks  required,  four  operators,  and  four 
operator  consoles,  are  required. 

6.3.4  DCF  Force  Planning  Element 

Communications  Interface:  The  interface  between  the  DCF  RPV  Planning  and 
Force  Monitoring  Element,  and  other  DCF  elements,  have  been  described  in 
preceding  subsections.  The  system  concept  provides  a  ground-to-ground  data 
link  between  elements  that  may  be  remoted.  The  interface  requirement  is 
easily  satisfied  by  a  low  data  rate  link.  If  elements  are  colocated  the  inter¬ 
face  is  internal  to  the  ADP  Support  system  and  is  implemented  through  a  con¬ 
sole  data  transfer  function.  1'he  TAGS  interface  is  similar,  from  a  system's 
view,  to  the  485L.  System  interface  between  the  TACC  and  a  Data  Source  term¬ 
inal.  Another  interface  required  is  for  track  tell.  A  data  link,  TADIL  B,  is 
required  to  tell  the  RPV  track  data  to  the  TACC  or  the  CRC  (it  is  assumed 
that  distribution  within  the  TACS  is  provided).  A  final  interface  is  to  the  re¬ 
lay  aircraft  which  thi element  must  control.  This  interface  can  be  through 
the  DCF,  Multiple  RPV  Control  Element.  None  of  these  interfaces  impose 
any  system  requirements  that  cannot  be  easily  satisfied. 
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ADP  Support  Requirements:  If  all  applications  programs  described  in  Sec¬ 
tions  3  and  4  are  implemented  to  support  RPV  mission  planning  the  ADP  Sup 
port  Requirements  for  the  RPV  Planning  element  are: 

Data  Base  Required:  4  to  6  million  bytes 

Applications  Programs:  162.6  Kls 

Operating  System:  74.  8K  bytes 

If  the  requirement  for  automated  support  for  weapon  selection,  automatic 
route  selection,  and  terrain  masking  were  eliminated  the  ADP  Support  Re¬ 
quirements  would  be  reduced  to: 

Data  Base  Requirement:  Approximately  2  to  3  million  bytes 

Applications  Programs:  132.8KIs 

Operating  System:  74.  8K  bytes 

The  principal  saving  is  in  the  data  base  which  can  be  maintained  in  bulk 
storage. 

If  the  requirement  for  automatic  support  is  reduced  to  a  minimum  support 
level,  that  is  selected  to  include: 

o  Route  Profil  5  Coding. 

o  Semi  Automatic  Route  Planning. 

o  Route  Safety  Scoring. 

o  Relay  Communication  LOS  Masking  &  Flight  Profile  Planning. 

The  ADP  Support  Requirement  would  reduce  to: 

Data  Base  Required:  Approximately  1  million  bytes 

Applications  Programs:  55.9  Kls 

Operating  System:  50  to  60K  bytes 

Operator,  Operator  Facilities:  Assuming  a  3  unit  RPV  force  with  each  unit 
capable  of  executing  80  missions  per  day  with  20  RPVs  simultaneously  air¬ 
borne,  the  system  must  provide  the  capability  to  plan  240  missions  and  con¬ 
trol  60  RPV  missions  simultaneously.  The  operator  loading  associated  with 
this  activity  depends  upon  many  factors  such  as: 

a.  The  planning  time  allowed:  The  assumption  is  that  the  planning 
response  time  is  comparable  to  that  specified  in  the  485L  sys¬ 
tem.  That  is  RPV  Mission  Planning,  which  includes  detailed 
mission  planning,  should  be  completed  in  four  to  six  hours. 


b.  Abort  rates,  divert  rates,  and  the  requirements  to  plan  immed¬ 
iate  missions:  The  assumption  is  that  these  factors  are  com¬ 
parable  to  those  specified  for  the  485L  system. 

With  these  assumptions,  and  based  on  the  time  required  to  plan  a  single 
mission  as  developed  from  SEEK  FLEX  and  TACC  simulations  and  MPS  ex¬ 
perience,  it  is  estimated  that  4  or  5  planners  can  plan  all  missions  in  six 
hours  or  less.  A  minimum  requirement  is  four  planning  consoles,  one  each 
for  Strike,  EW,  and  RECCE  missions,  with  the  fourth  console  allocated  to 
a  fourth  planner  for  any  mission  type  as  required.  For  mission  monitoring 
one  operator  for  each  mission  type  is  minimum  with  one  supervisory  con¬ 
sole.  Based  on  these  assumptions  and  for  a  three  unit  force  the  minimum 
operator  requirements  are  eight  operators  and  eight  operator  consoles.  It 
is  probable  that  this  minimum  also  satisfies  the  operational  requirements. 

6.4  SYSTEM  CONFIGURATION 

6.4.1  Introduction 

A  given  RPV  Force  consists  of  a  RPV  composite  group  with  three  RPV  units. 

1)  An  RPV  Strike  Unit 

2)  An  RPV  EW  Unit 

3)  An  RPV  REECE  Unit  or 
Three  Composite  Units 

Each  unit  is  capable  of  launching  80  missiors  (sortie*)  per  day  with  20  mis¬ 
sions  simultaneously  airborne.  The  RPV  Command  and  Control  System 
must  be  capable  of  simultaneously  controlling  60  missions  with  four  of  these 
missions  in  the  weapon  delivery  phase.  The  planning  element(s)  must  be 
capable  of  planning  240  missions  per  day.  To  provide  the  required  Command 
and  Control  there  are  several  ways  in  which  the  system  elements  can  be  com¬ 
bined.  This  subsection  presents  four  configurations  which  are  possible  and 
addresses  the  advantages  and  disadvantages  of  each. 

6.4.2  Centralized  Configuration 

In  this  configuration  (Figure  6,4-1)  all  system  elements  are  colocated.  Such 
a  centralized  Command  and  Control  facility  would  most  probably  be  located 
at  the  RPV  Composite  Group  level.  It  applies  to  any  unit  deployment  but  may 
be  most  applicable  if  the  deployed  units  are  Composite  units.  The  system 
components  required  are  three  DCF,  Multiple  RPV  Control  Elements,  one 
DCF,  Weapon  Delivery  Control  Element,  and  a  DCF  RPV  Planning  and  Force 
Monitoring  Element  with  redundant  components  reduced  as  follows. 

Operator  Positions  and  Operator  Consoles:  The  individual  elements  as  de¬ 
fined  include  a  supervisory  position  in  each  DCF  Multiple  RPV  Control  Ele¬ 
ment  which  was  sized  for  unit  control.  In  addition  there  were  three  mission 
monitoring  positions,  and  one  supervisory  position  in  the  DCF,  RPV  Planning 
and  Force  Monitoring  Element.  This  is  a  total  of  seven  monitoring  and  super 
visory  positions.  In  the  Centralized  Configuration,  3  monitoring  positions 
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Figure  6.4-1.  Centralized  RPV  Command  and  Control  System 


and  one  supervisory  position  would  probably  satisfy  the  requirements,  thus 
saving  three  operator  positions  and  three  operator  consoles. 

Communication  Requirements:  The  communication  requirements  for  the 
Centralized  Configuration  are  the  sum  of  the  communications  of  the  indivi¬ 
dual  elements.  The  implementation  of  several  interfaces  are  affected  how¬ 
ever.  Inter-element  interfaces  can  be  implemented  internal  to  the  ADP 
Support  System  with  a  corresponding  elimination  of  the  need  to  interface 
remoted  DCF  elements  by  ground  data  links.  Offsetting  this  is  an  increased 
requirement  to  interconnect  the  centralized  facility  with  all  launch  and  re¬ 
covery  sites.  The  interface  to  the  Relay  Aircraft  introduces  factors  on 
relay  aircraft  sizing  and  relay  aircraft  control  that  have  not  been  previously 
addressed.  Assuming  however  that;  1)  a  relay  aircraft  is  sized  to  communi¬ 
cate  with  20  RPVs  simultaneously,  and  2)  the  use  of  multiple  relay  aircraft 
when  operational  requirements  dictate  is  independent  of  the  RPV  Command 
and  Control  system  configuration  and  3)  control  of  the  relay  aircraft  will  be 
allocated  to  the  DCF,  RPV  Planning  and  Force  ControlElement;  then  com¬ 
munications  relay  interface  requirements  are  independent  of  the  RPV  Com¬ 
mand  and  Control  System  Configuration.  The  third  primary  interface,  inter¬ 
face  and  the  TACS,  is  assumed  to  be  through  the  DCF,  RPV  Planning  and 
Force  Control  Element  in  ail  configurations  and  is  therefore  also  configura¬ 
tion  independent. 

ADP  Support  Requirements:  The  centralized  facility  can  be  supported  by 
an  integrated  ADP  Support  System  with  the  usual  cost  saving  that  results 
from  eliminating  the  need  to  duplicate  data  bases,  operating  systems,  and 
applicable  program  requirements.  The  amount  of  ADP  System  capacity  that 
can  be  saved  depends  upon  the  amount  of  duplication  in  a  distributed  system. 
For  this  particular  system  there  is  no  significant  duplication  in  the  data  base 
requirements  of  the  DCF,  Multiple  RPV  Control  Element.  The  total  data 
base  required  in  the  centralized  system  is  approximately  the  sum  of  the 
total  data  base1  requirements  of  the  individual  elements.  The  application 
programs  for  the  DCF  basic  control  element  need  not  be  duplicated  saving 
storage  for  3.6  KIs.  The  principal  saving  in  the  Centralized  ADP  Support 
System  as  against  a  distributed  system  is  in  the  system  operational  support 
software.  One  operational  support  system  is  required,  not  three,  which 
indicates  an  apparent  saving  of  78. 4K  bytes  storage.  Offsetting  this  however, 
is  the  consideration  that  the  centralized  ADP  System  will  require  a  more 
capable,  hence  somewhat  larger,  OS  system  which  reduces  the  apparent 
savings  in  storage  and  increases  somewhat  the  cost  of  providing  the  OS 
system.  The  conclusion  from  these  general  considerations  is  that  in  this 
system  the  cost  savings  of  a  Centralized  System  as  against  a  distributed 
system  that  will  be  described  is  relatively  small. 

Maintenance  Support;  The  Centralized  System  concept  contains,  within  itself, 
centralized  maintenance  support.  It  is  normally  evident  that  a  centralized 
facility  can  be  maintained  at  a  cost  significantly  less  than  a  decentralized 
system.  The  quantitative  savings  are  dependent  on  the  system  maintenance 
concepts,  failure  rates  and  the  degree  to  which  one  dispersed  element  can 
back  up  another. 
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Considering  all  factors  that  impact  coat,  it  is  concluded  that  the  Centralized 
Configuration  for  the  RPV  Command  and  Control  System  can  be  provided  at 
a  cost  saving,  as  against  a  decentralized  system.  The  cost  savings  are, 
however,  relatively  small  when  compared  to  total  system  costs. 

Operational  Concepts:  The  other  factors  to  consider  are  the  operational 
factors.  There  is  no  obvious  operational  advantage  in  a  centralized  con¬ 
figuration.  The  element  interfaces  are  not  more  effective.  There  are  no 
significant  person  to  person  interface  requirements  that  are  enhanced. 

There  are  a  number  of  operational  disadvantages  in  the  centralized  con¬ 
figuration.  First,  any  centralized  system  is  inherently  more  vulnerable  to 
enemy  attack.  Secondly,  being  larger  it  is  less  mobile,  and  set-up  time  is 
longer.  Finally,  the  savings  in  the  centralized  system  were  in  part  realized 
by  reducing  system  redundancy  which  makes  the  system  more  vulnerable 
when  system  components  fail.  The  operational  advantages  of  a  decentralized 
system  which  is  designed  to  provide  element  back-up  include  increased  sur¬ 
vivability,  increased  capability  to  function  in  degraded  modes,  and  increased 
mobility  which  includes  the  capability  to  relocate  in  a  leapfrog  mode.  These 
features  are  all  disadvantages  of  a  centralized  system. 

Considering  the  fact  that  the  RPV  system  must  be  designed  to  operate  in  a 
mobile  tactical  environment,  disadvantages  of  the  centralized  system  seem 
to  far  outweigh  the  advantages. 

6.4,3  Decentralized  Configuration  A: 

This  configuration  is: 

a,  A  DCF,  Multiple  RPV  Control  Element  at  each  RPV  unit. 
(Figure  6,4-2  depicts  RPV  units  as  mission  unique,  but 
Composite  units  may  be  deployed). 

b,  The  DCF,  Multiple  RPV  Control  Element  at  the  Strike 
RPV  unit  augmented  with  the  DCF,  Weapon  Delivery  Con¬ 
trol  Element. 

c,  A  DCF,  RPV  Planning  and  Force  Control  Element  colocated 
with  the  Strike  RPV  Unit  DCF. 

In  this  configuration,  (Figure  6.4-2)  the  system  elements  that  provide  phy¬ 
sical  control  of  the  RpVs  and  monitoring  at  the  unit  level  are  decentralized, 
and  the  RPV  Planning  and  Force  Monitoring  functions  are  centralized  as 
in  the  centralized  configuration  described.  The  cost  factors  are  the  con¬ 
verse  of  those  described  for  the  centralized  facility.  Three  more  operator 
positions  and  three  more  operator  consoles  are  required.  These  operators 
and  operator  consoles  provide,  however,  increased  system  redundancy  with 
the  attendant  capability  to  handle  transient  overloads,  or  to  function  with  no 
loss  of  operational  effectiveness  in  the  event  of  system  failures.  The  fact 
that  the  DCF  Multiple  RPV  Control  Elements  do  not  significantly  require 
duplicated  data  bases  and  that  the  application  program  requirements  are 
small,  means  that  it  is  the  operating  system  (39.  2K  Bytes)  that  is  the  only 
significant  duplicated  component.  As  indicated  in  the  previous  subsection, 
maintenance  costs  will  be  increased. 
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Figure  6.4-2  Decentralized  Configuration,  RPV  Command  And  Control  System,  Centralized 
Planning  And  Force  Monitoring,  Decentralized  Control 


All  factors  considered,  it  is  a  subjective  conclusion  that  the  advantages  of 
the  Decentralized  Configuration  A,  when  compared  to  increased  costs,  are 
such  that  configuration  A  is  preferred  over  the  centralized  configuration. 
This  is  especially  true  if  the  units  are  mission  unique  as  depicted  in  the 
figure. 

6. 4. 4  Decentralized  Configuration  B 

This  configuration  (Figure  6.4-3)  is  identical  to  Decentralized  Configuration 
A  except  that  the  force  planning  element  is  collocated  with  the  TACC  rather 
than  at  the  Strike  RPV  Unit  DCF.  It  applies  to  mixed  force  deployments 
only  since  for  &  pure  RPV  Force  the  DCF  Force  Planning  element  functions 
as  the  TACC.  The  cost  factors  of  Configuration  B,  as  against  Configura¬ 
tion  A,  relate  almost  exclusively  to  how  the  automated  TACC  of  the  485L 
system  is  designed,  the  specific  capability  provided  in  the  RPV  Force  Plan¬ 
ning  Figment,  and/or  the  degree  to  which  the  Air  Force  desires  to  apply 
the  capability  of  the  RPV  Force  Planning  Element  to  the  planning  of  manned 
systems.  The  factor  that  enters  into  selecting  this  configuration,  as  against 
Configuration  A,  are  primarily  of  a  Command  nature. 

6.  4.  5  Decentralized  Configuration  C 

This  configuration  (Figure  6.4-4)  is  similar  to  Decentralized  Configuration 
A,  except  that  force  planning  is  decentralized  to  the  RPV  unit  level.  The 
cost  factor  is  relatively  high  since  the  data  base  and  program  requirements 
of  the  individual  planning  elements  are  almost  the  same  as  for  the  central¬ 
ized  planning  element.  Not  only  are  the  cost  factors  high,  but  there  are 
operational  disadvantages  in  decentralizing  planning,  including  communi¬ 
cations  relay  planning  delegated  to  the  unit  level.  It  is  concluded  that  this 
configuration  is  not  compatible  w  th  the  operational  requirements,  and  that 
the  cost  is  high.  Table  VI.  4-1  is  a  summary  chart  of  the  four  configurations 
It  presents  data  on  the  comparative  manning  levels  and  ADP  requirements 
for  each  configuration.  The  advantages  and  disadvantages  are  also  sum¬ 
marized. 

6.4.6  Airborne  Options 

There  are  several  viable  airborne  options.  One  is  to  provide  the  DCF 
Multiple  RPV  Control  Element  in  an  airborne  command  post.  Considering 
the  system  size,  this  is  quite  feasible.  The  considerations  are  primarily 
dependent  upon  a  Command  selection  of  an  opei’ational  mode  ar  d  outside  the 
scope  of  this  study.  Another  possibility  is  to  provide,  over  th;  target  con¬ 
trol,  the  DCF  Weapon  Delivery  Control  Element,  on  an  airborne  platform. 

If  the  Weapon  Delivery  Control  Element  is  stripped  to  its  essential  elements, 
a  fighter  aircraft  could  be  configured  to  provide  Weapon  Delivery  Control. 

By  overflying  enemy  territory  communications  requirements  ctuld  be  con¬ 
siderably  reduced.  While  the  latter  option  has  many  attractive  features 
there  is  one  significant  operational  disadvantage,  overflight  of  enemy  terri¬ 
tory  is  required.  As  with  other  options  mentioned,  the  primary  considera¬ 
tions  in  rejecting  or  pursuing  this  option  are  operational. 
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Figure  6.4-4  Decentralized  Configuration  C,  RPV  Pianrting/Reptanning  Decentralized  to  RPV  Unit 


Table  VI.  4-1.  Summarized  Features  of  Four  Configuration  Concepts 


Decentralized  Configuration  Z\  DB:  4.5  to  6,5  K  Bytes  *  backup. 

"A"  or  "B1'  Total  AP’s:  176.4  Kl'a 

O/S:  50.  1  to  52.  1  K  Bytes 


Summarized  Feature*  of  F e»itv  C en-.fi $.« v Alton  Concepts,  Continued 


SECTION  7 


SUMMARY  OF  FACTORS  AFFECTING 
RPV  C&C  AND  RECOMMENDATIONS 


7.  1  SUMMARY  OF  FACTORS  AFFECTING  RPV  COMMAND  AND 
CONTROL 

Since  the  RPV  System,  the  RPV  Command  and  Control  System,  and  the 
operational  concepts  for  the  use  of  RPV  are  evolving  concurrently,  there 
are  many  areas  that  can  be  identified  as  requiring  further  study  and  analysis. 
At  the  highest  level  there  are  trade-offs  between  the  total  system  capability 
and  total  system  coats.  At  lower  levels  there  are  trade-offs  between  the 
RPV  vehicle  system  element  and  its  onboard  avionics,  the  communications 
and  navigation  system  elements,  and  the  command  and  control  elements. 
Within  each  element  many  trade-offs  exist.  Within  the  total  pyramid  of 
trade-off  options,  the  objective  is  to  achieve  an  optimum  balance  between 
RPV  system  capability  and  RPV  system  costs  within  a  concept  of  use  that 
optimally  balances  the  RPV  weapon  system  capabilit*'  and  the  capability  of 
manned  weapon  systems. 

In  the  analysis  of  the  RPV  Command  and  Control  System  which  Litton  con¬ 
ducted,  many  areas  were  identified  where  viable  options  exist  which  affect 
Command  and  Control  System  requirements  cr  whore  further  analyses  are 
required  to  develop  the  Command  and  Control  fystem  requirements.  Table 
VU.l-T,  Summary,  RPV  System  Factors  Affecting  RPV  C&C,  lists  the 
principle  factors  that  impact  the  RPV  Command  and  Control  System  per¬ 
formance  parameters.  These  factors,  identified  as  "trade-off,"  relate  to 
alternative  con*munication  approaches  that  affect  Command  and  Control 
communication*.  Those  factors  identified  as,  "Baeeline  Assumptions,  " 
relate  to  the  capability  of  elements  of  the  RPV  system  which  impact  the 
Comms.no  and  Control  option*.  Variations  to  such  a  baseline  need  to  be 
assessed  in  terms  of  the  effects  or.  the  ground  baaed  Command  and  Control. 
The  notation,  "further  analysis  required,"  indicates  that  a  more  detailed 
analysis  is  required  to  establish  the  system  requirements  for  APP  Support, 
Operator  facilities,  operator  time  required,  and  the  associated  communi¬ 
cations  requirements.  The  .‘section  reference  is  to  the  Section  of  this  re¬ 
port  where  that  System  Factor  is  diecusscd.  The  consideration  in  each  of 
those  areas  are  discussed,  briefly,  in  the  following  paragraphs. 

7.1.1  Communication  Subsystem  Characteristics  (Ref.  Section  2. 7.  1) 

This  section  lists  some  cf  the  characteristics  of  the  communication  sub¬ 
system  which  appear  to  bo  desirable,  as  well  as:  communications  technology, 
RPV  system  requirements,  and  cost  effectiveness  parameters  considered. 
Many  alternatives  that  exist  are  identified  in  Litton's  study  and  previous 
Air  Force  funded  etudies.  The  principle  factors  affecting  the  trade-offs 
which  are  external  to  the  Communication  Subsystem  relate  to  the  capability 
of  the  RPV  on-board  avionics,  and  to  the  operational  re qtiirements  for 
communication  on  demand  versus  periodic  Communications  for  the  Com¬ 
mand  and  Response  link(s). 


Table  VII.  1-1.  Recommended  Study  Areas 


Recommended  Study  Areas 

Section  Reference 

1.  Communication  Subsystem  Characteristics 

2.7.1 

(Baseline  Assumptions). 

2.  Use  of  Command  Response  link  for  RPV 

2.7.6  and  2.7.9 

range  measurements  and  location  (trade- 

off). 

3.  Use  command  response  link  frequency  band 

2. 7. 6  and  2. 7. 9 

and  RF  hardware  to  measure  terrain  clear- 

ance  (trade-off). 

4.  Use  HF  for  a  one  way  command  link  from 

2.7.9 

DCF  to  Abn  RPVs,  RPV  response  through 

a  relay  (trade-off). 

5.  RPV  Avionics  subsystem  characteristics 

3. 2, la,  b,  and  c 

(Baseline  a g  sumption  a). 

6,  Command  Response  Links,  Weapon  Delivery 

3.2.2 

v  and  Fai route  Control  (Baseline  Assumptions). 

7.  Navigation  Subsystem  Characteristics 

3.2.3 

(Baseline  Assumptions). 

8,  RPV  Position  and  Status  Reporting 

3.?..  4 

(Baseline  assumptions). 

9,  Multiple  Vehicle  Control  Procedures 

3.2.5.  1 

(Baseline  assumptions), 

10,  Operator  time  required  for  control  of 

3. 2. 5. 4 

multiple  RPVs  (further  analysis  required). 

11.  Requirements  for  target  acquisition  and 

3. 2. 6. 8 

control  of  weapon  delivery  and  bomb 

damage  assessment  (further  analysis 

required). 

12.  Automatic  Route  Adjustment  implementation 

3. 3. 2. 4 

(further  analysis  required). 

13.  Procedure  for  Relay  A/C  route  profile  plan- 

3,3.4,  3.3.5 

sing  and  immediate  replanning  (further 

and  3.  3. 9. 4 

analysis  required). 
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Table  VII,  1-1.  Recommended  Study  Areas  (cont) 


Recommended  Study  Areas 

Section  Reference 

14.  Develop  quantitative  parameters  for  ADP 
support  for  RPV  Command  and  Control 
(software,  data  base,  processor)  (further 
analysis  required). 

Section  5 

7.1.2  Use  Command  Response  Link  For  RPV  Range  Measurement  (Ref. 
2,7,6  and  2.7,9) 

Given  that  an  airborne  relay  is  required  and  that  communications  security 
nnd  xtJ  protection  must  be  provided,  it  is  not  technically  difficult,  nor 
costly,  to  add  a  range  measuring  capability.  With  two  airborne  relays, 
location  data  are  easily  achieved,  providing  a  completely  self  contained  and 
aco,*rat*  navigation  system  for  RPVs.  The  necessity  to  provide  two  relay 
aircraft  may  increase  operating  costs  during  the  low  activity  periods. 

There  is,  however,  the  possibility  of  using  a  low  cost  relay,  designed 
specifically  for  enroute  control  only,  which  may  reduce  relay  aircraft  costs, 
thus  making  two  airborne  relays  cost  effective.  Additionally,  several  poa- 
sioilities  of  providing  adequate  position  data  using  one  relay  aircraft  are 
available.  However,  multiple  trade-offs  are  involved. 

7.1.3  Use  Command  Response  Link  Frequency  Band  and  RF  Hardware  to 
Measure  ferrain  Clearance  (Ref.  2.  7.  o  an^  2.7.  *9]" 

This  is  an  extension  of  item  7, 1,2  above.  The  possibility  of  low  costter- 
rain  clearance  capability,  using  the  command  response  link  RF  hardware, 
is  available. 

7.1.4  Use  HF  for  One-Way  Command  Link  From  DCF  To  Airborne 
RPVs  (Ref.  2.779) 

This  option  has  the  promise  of  reducing  significantly  the  link  capacity  re¬ 
quired  of  the  communications  relay  aircraft  links,  thus  easing  the  AJ 
problem  and  providing  a  possible  means  of  acceptable  location  data,  using 
communications  ranging  techniques  and  only  one  relay  aircraft. 

7.1.5  RPV  Avionics  Subsystem  Characteristics  (Ref.  3.2.1,  Sub  Para¬ 
graphs  a. ,  b, ,  and  c. ) 

This  section  lists  some  of  the  capabilities  of  the  RPV  avionics  subsystems 
.which  appear  to  be  necessary  or  desirable  in  order  to  provide  a  multiple 
RPV  Control  Capability,  Any  change  in  these  assumptions  could  signifi¬ 
cantly  impact  the  communications  required  for  RPV  Command  and  the 
Control, 
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7.1.6  Command.  Response  Links,  Weapon  Delivery  Control  And  Enroute 
Control  (Ref.  3.2.2) 


This  section  assumes  two  command  response  links  are  provided;  one  pro¬ 
vides  periodic  contacts,  the  other  communication  on  demand.  The  assess¬ 
ment  is  that  this  provides  thfe  required  operational  capability  at  die  lowest 
cost.  Any  change  in  this  assumption  could  significantly  affect  the  relay 
link  capacity  requirements. 

7.1.7  Navigation  Subsystem  Characteristics  (Ref.  3.2.3) 

To  minimise  the  cost  of  RPV  Avionics,  it  is  assumed  that  calculations 
needed  to  interpret  the  navigation  system  signals  and  calculate  RPV  posi¬ 
tion  is  allocated  to  the  ground  based  processor.  Any  change  in  the  assump¬ 
tion  affects  the  RPV  on-board  avionics  subsystem  and  the  communication 
and  control  requirements. 

7.1.8  RPV  Status  And  Position  Reporting  (Ref.  Section  3.2.4) 

Assumptions  are  documented  on  status  and  position  data  reported  and  on 
the  update  rates.  Communications  and  control  requirements  are  dominated 
by  these  assumptions.  Any  change  in  assumptions  can  very  significantly 
affect  communication  and  DCF  processing  requirements. 

7.1.9  Multiple  Vehicle  Control  Procedures  (Ref.  3.2.5. 1) 

The  principal  options  addressed  relating  to  enroute  control,  are;  1)  pre¬ 
programmed  and  preloaded  vehicle  control  instructions  with  corrective 
controls  issued  as  required  and,  2)  all  control  instructions  initiated  by  the 
DCF  as  required  to  fly  the  preplanned  profile.  The  option  selected  to 
assess  the  DCF  performance  parameters  was  1)  above,  preprogrammed 
Control  with  Corrective  Commands  issued  as  required.  Any  change  in  this 
assumption  may  significantly  affect  communications  required  and,  quite 
possibly,  operator  requirements. 

7.1.10  Operator  Time  Required  For  Multiple  RPV  Control  (Ref.  3. 2. 5.  4) 

Operator  time  required  for  multiple  RPV  control  is  dependent  on  many 
assumptions  regarding  operator  activities.  These  assumptions  include 
operational  factors  such  as  mission  rates,  abort,  and  adjustment  rates. 
Further  analysis,  and  some  type  of  simulation,  is  required  to  establish 
how  these  variables,  coupled  with  alternatives  in  control  procedures, 
affect  grade  of  service. 

7. 1 . 11  Requirements  For  Target  Acquisition  And  Weapon  Delivery  And 
feomh  iba^ge  Assess'ment  (Reir  i.^.&r  *  "  ~  " 

The  principle  trade-offs  In  this  area  relate  to  the  transmission  of  video  data 
and  the  operator  target  recognition  problem.  These  trade-off  factors  are 
internal  to  the  video  data  transmission  procoseing  and  display  element  and 


do  not  significantly  affect  the  requirements  for  the  command  response  data 
link  nor  the  number  of  operators  required  (operator  requirements,  one  on 
one,  are  assumed).  These  factors  were  not  analysed  under  Litton' s  study. 
The  other  alternatives  that  affect  the  command  response  data  link  require¬ 
ments  and  the  rate  at  which  a  single  operator  can  accept  control  of  weapon 
delivery  depend  on  variables  such  as  requirements  for  weapon  release  cal¬ 
culations  and  operator  control  required  for  bomb  damage  assessments,  es¬ 
cape,  and  reattack.  Further  analysis  and  some  type  of  simulation  is  re¬ 
quired  to  establish  how  these  variables  affect  communications  requirements 
and  operator  time  required  per  attack. 

7.1.12  Automatic  Route  Adjustment  Implementation  (Ref.  3.  3. 2. 4) 

The  size  of  the  data  base  and  the  application  program  required  to  implement 
automatic  route  adjustment  can  vary  depending  upon  the  specific  method 
selected  for  coding  threat  data.  The  ADP  support  requirements  presented 
in  Table  V.  2-3  (Section  5)  assumed  a  specific  approach.  Further  analysis 
is  needed  to  establish  that  the  specific  approach  selected  is  the  most  econo¬ 
mical. 

7.1.13  Procedure  For  Relay  A/C  Route  Profile  Planning  And  Immediate 
Replanning  (Ref.  3.3.4,  3.  3.  5  and  3.  3.  9.4) 

The  planning  for  the  relay  aircraft  route  profile  introduces  many  new 
variable  factors  in  mission  planning.  To  adequately  assess  all  factors  re¬ 
quires  a  quite  detailed  assessment  of  the  operating  environments,  opera¬ 
tional  procedures,  and  the  diurnal  distribution  of  RPV  missions  to  be  con¬ 
trolled,  Also,  some  type  of  simulation  is  indicated. 

7.1.14  Develop  Quantitative  Parameters  for  ADP  Support  (Ref.  Sections) 

The  factors  identified  as  software,  data  base,  and  processor  are  inter¬ 
related.  The  requirement  is  to  develop  in  more  detail  the  ADP  software 
requirements  to  support  the  ground  based  command  and  control,  the  associ¬ 
ated  data  base  requirements,  and  to  establish  the  processing  capability 
required  of  the  computer  to  provide  timely  response  under  load. 

7.2  RECOMMENDATIONS 

The  factors  summarized  in  the  preceding  subsection  are  of  two  types.  One 
relates  to  the  RPV  subsystem  performance  parameters,  the  communications 
and  navigation  subsystems,  and  RPV  on-board  avionics  which  affect  the  RPV 
Command  and  Control  procedures  and  the  Command  and  Control  subsystem 
performance  parameter#  (trade-off  factors  and  baseline  assumptions).  The 
other  factors  relate  to  the  requirement  for  further  analysis  to  develop 
quantitative  parameters  on  the  Command  and  Control  system  loads,  commu¬ 
nications  system  loading,  processing  and  display  requirements,  and  operator 
loading.  The  variables  affecting  the  command  control  system  load  are  of 
three  types;  1)  the  RPV  subsystem  performance  parameters  which  affect 
Command  and  Control,  2)  Alternative  RPV  Command  and  Control  subsystem 
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and,  3)  Operational  employment  concepts  and  force  level  factors  which  im¬ 
pose  performance  requirements  on  the  RPV  Command  Control  system.  At 
the  system  level  it  is  important  to  be  able  to  assess  the  effect  of  these 
variables,  singly  and  in  combination. 

Over  the  past  several  years,  Litton  has  used  a  relatively  simple,  but 
powerful  simulation  model  to  examine  Command  and  Control  system  para¬ 
meters  with  emphasis  on  communications,  computer,  and  operator  load 
factors.  Under  the  SEEK  FLEX  study  the  model  was  developed  to  specifical¬ 
ly  analyze  ADP  support  parameters.  The  "Load  Model"  was  used  to  develop 
computer  loads  that  were  then  used  to  drive  a  simulation  model  of  vhe  SEEK 
FLEX  computer.  Under  the  TACC  study,  the  model  was  developed  further 
to;  1)  make  it  easier  to  use,  2)  provide  more  flexibility  in  its  operation, 
and  3)  provide  more  useful  outputs. 

A  document,  "A  User-Oriented  Aid  For  System  Load  Analysis,"  prepared 
for  Litton* s  internal  use,  describes  the  simulation  model  in  operational 
terms.  It  is  attached  to  this  report  as  Appendix  B.  Since  that  document 
was  written,  the  model  has  been  further  developed  to  incorporate  task 
priorities  and  queueing.  The  model  can  be  used  without  modification  to 
simulate  the  activity  of  an  RPV  Command  and  Control  system. 

Specifically,  the  model  can  be  used  to  establish  the  parametric  relationship 
between  the  RPV  Command  and  Control  subsystem  and  factors  external  to 
the  Command  and  Control  subsystem.  The  Command  and  Control  subsystem 
parameters  that  can  be  developed  include: 

a.  Communications  link  requirements,  bits  per  second  by  link. 

b.  Operator  and  operator  facility  requirements,  number  required 
to  achieve  a  specified  grade  of  service. 

c.  Data  processing  requirements,  data  base  (number  of  bytes), 
software  program  size  (numbered  instructions),  and  pro¬ 
cessing  rates  (kilo  instructions  executed  per  second). 

The  factors  which  can  be  easily  varied  to  assess  the  quantitative  effects 
of  viable  options  include: 

a.  RPV  system  capability  factors  such  as  RPV  on  board  avionics, 
communications,  and  navigation  subsystem  performance 
parameters. 

b.  Command  Control  Subsystem: 

•  Functional  allocations;  man  and  machine, 

•  Implementation  of  functional  processes. 

•  Command  and  Control  procedures. 


c.  Force  Size  Factors: 


•  Number  of  sories  per  day. 

«  Number  of  missions  per  day. 

•  Mission  Mix. 

•  Number  of  simultaneous  missions  by  type  and  phase, 
d.  Operational  Factors: 

•  Ratio  of  preplanned  to  immediate  missions. 

•  Abort  rate  and  adjustment  rate. 

a  Number  of  targets  per  mission  planned,  and  executed. 

a  Response  time  requirements. 

The  feature  of  the  model  which  makes  it  a  particularly  useful  tool  to  assess 
system  trade-offs,  and  the  effect  of  system  trade-offs  on  the  Command 
Control  and  Communication  subsystems,  is  that  once  the  system  model  has 
been  structured  the  variable  parameters  are  easily  changed.  Many  alterna¬ 
tives  can  be  assessed,  singly  or  in  combination,  at  relatively  low  cost. 
Typically,  to  assess  the  effect  of  a  system  variable,  a  model  parameter  is 
changed  and  the  model  is  rerun.  To  exploit  the  capability  of  Litton' s  com¬ 
mand  and  control  system  load  simulator,  it  is  recommended  that  the  Air 
Force  consider  a  study  to  simulate  the  RPV  CfcC  system  using  Litton 's 
Load  Model.  The  benefits  that  will  be  derived  will  provide  insight  into  th<* 
affects  of  System  Load  trade-offs  on  RPV  Command  Control  and  Communi¬ 
cations  and  the  affects  of  alternative  command  and  control  procedures  on 
RPV  System  performance. 
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APPENDIX  A 

RPV  PLANNING  DEMONSTRATIONS  AND  RESULTS 

INTRODUCTION 

On  23  August  1972,  a  Mission  Planning  System  Breadboard  demon¬ 
stration  was  given  at  the  Litton  Computer  Facility  in  Canoga  Park, 
California,  to  demonstrate  RPV  planning.  This  demonstration 
satisfied  subparagraphs  4. 1.3. 3. 3  and  4. 1.3,;’;. 4  of  Contract 
P30602-71-C-001 5,  Change  "C",  6  July  1972.  It  also  satisfied 
in  part  all  of  paragraph  4. 1.1, 3. 3. 

The  scope  of  the  present  RPV  study  did  not  *llow  for  extensive 
changes  to  the  MPS  breadboard.  It  was  desired  to  make  very  few, 
if  any,  coding  changes  and  to  minimize  changes  to  the  data  base. 

To  this  purpose  an  existing,  non- classified  North  Korea  data  base 
was  used.  This  meant  that  the  map  and  the  BOB  did  not  have  to  be 
changed.  The  following  paragraphs  discuss  the  changes  that  were 
made  to  the  data  base  and  programs. 

DATA  BASE  UPDATE  AND  PROGRAM  MODIFICATIONS 

The  purpose  of  this  section  is  to  describe  the  changes  made  to 
the  data  base  of  the  Mission  Planning  System  Breadboard  to  satisfy 
subparagraph  4, 1.1. 3. 3, 2  of  the  contract.  It  was  also  necessary 
to  make  minor  modification  to  the  programs  in  order  to  run  the 
system  for  RPV  planning.  These  minor  modifications  are  also 
described  in  this  section. 

The  following  references  were  used. 

1.  Study  of  Multi-Mission  RPV  Systems 

Pinal  Technical  Report,  Northrop  Corp.,  SS-1494 
2*  An  Analysis  of  Remote  Manned  Systems  for  Attacking  SAM  Site 
Rand  Corp.  SS-163B 


The  following  assumptions  were  made: 

1.  The  RPV  aircraft  has  a  maximum  operating  range  of  approxi- 
■ately  200  miles  and  weapon  load  limits  of  approximately 
2000  lbs . 

2.  There  are  only  three  stations  on  which  weapons  can  be 
carried. 

3.  AGM-65A  (Maverick)  type  missile  is  carried  in  the  place 
of  AMG  12-C  (Bui 1 pup  B). 

4.  No  fire  bomb  or  incendiary  bomb  will  be  carried. 

5.  The  weapon  delivery  tactics  is  as  follows: 

a .  Por  AGM-  65A ; 

Dive  angle  »  30° 

Release  Altitude  =  7000’ 

True  air  speed  «  600  knots 

b.  Otherwise: 

Dive  angle  »  43  0 
Release  Altitude  »  3000’ 

True  air  speed  *  600  knots 

Data  base  modules  changes  are  listed  as  follows: 

1.  Select  10  new  targets  for  the  RPV  type  mission  (TGTFXLE), 
Figures  1  to  10  show  detailed  information  for  these  new 
targets.  The  major  considerations  for  the  RPV  type  target 
list  were:  (1)  the  operating  range  of  RPV  aircraft  is 
approximately  200  miles*  (2)  the  operating  weapon  load  limit 
is  approximate! v  2000  lbs.,  (3)  RPV  weapon  delivery  tactics 
(dive  angle,  air  sp^ed.  iciease  altitude)  yield  higher 
effectiveness  against  point  targets  such  as  bridges,  bunkers 
buildings,  SAM  or  AAA  sites. 

These  new  targets  were  added  to  the  existing  target  file 
(TGTFXLB)  in  the  data  base. 

Z.  Create  a  new  mission  requirement  file  (MSNUEQF)  such  that 


the  new  missions  associated  with  10  new  targets  can  be 
selected  and  planned  by  RPVMPS. 

Figure  11  shows  the  tabular  display  of  mission  number  and 
target  information. 

Figure  12  shows  the  graphical  display  of  target  locations 
and  airbase  locations. 

3.  Modifications  were  made  to  the  airbase  (AIRBASE)  File  to 
reassign  aircraft  types  to  airbases,,  particularly,  the 
F-10SD  was  replaced  by  the  RPV001  vehicle,  and  the  RPVQ01 
vehicle  was  assigned  to  the  airbase  closest  to  FEBA  to 
satisfy  RPV  aircraft  operating  range. 

4.  The  Ordnance  Menu  (ORDMENU)  Pile  was  modified  to  include  a 
new  weapon,  AGM65-A  (Maverick)  air  to  ground  missile  for 
RPV  vehicle . 

5.  Figure  13  shows  the  various  target  types  included  in  the 
current  JHEH  table.  Figure  14  shows  the  various  ordnance 
(weapon) types  included  in  the  current  JKEM  table.  The 
ordnance  type  code  is  used  in  the  description  of  the  JMBM 
table. 
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Figure 11 


MISSION  PLANNING  SYSTEM 


TARGET  LIST 


*  ■  1  "  '  V  ■  M  1  ■ 

TARGET  CODE  1  TARGET  TYPE 


1 

2 

3 

4 

5 

6 

7 

8 
$ 

10 

11 

12 

13 

14 

15 

16 

17 

18 
19 

0 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 
33 

36 

37 
3i 

39 

40 


AREA  BARRACKS  280X170M  (FIRE  OR  50%) 

,  AREA  MIG-19  11X366M  OPEN  (KILL) 

*  AREA  MIG-19  91X1220M  REVETTED  (PTO) 
i.  AREA  PERS  300X300M  STAND  (12HR  SUP) 

!  AREA  STACKED  AMMO  72X106M  (KILL) 

!  FORWARD  AIRSTRIP  (KILL) 
i  AREA  55  GAL  POL  DRUMS  76X76M  (KILL) 
CONCRETE  DAM  3M  THICK  (KILL) 

!  CONCRETE  RUNWAY  10  THICK  (PTO) 

CONVOY  2.5TN  TRKS  6X5Q0M  (8HR  TRP) 
i  TUNNEL  STEEL  OR  CONCRETE 

CONVOY  7TN  TRKS  6X500M  (1.5HR  TRP) 

!  EARTHEN  DAM  6X30M  (KILL) 
i  MASONRY  ARCH  BRIDGE  (DROP  ONE  SPAN) 

»  MASONRY  BLDG  12X12M  CFIRE  OR  50%) 
t  ONE  LARGE  HANGER  (KILL) 

;  ONE  POL  TANK  9N  DI AM  X  7M  HIGH  (KILL) 
?  ONE  SMALL  HANGER  (KILL) 

RAIL,  SINGLE  TRACK  (CUT  ONE  RAIL) 
SIMPLE  GIRDER  BRIDGE  (DROP  1  SPAN) 
TRUSS  BRIDGE  (DROP  ONE  SPAN) 

AREA  PERS  30X300M  FOXHOLE  <30S  DBF) 
AREA  PERS  30X300M  PRONE  (S  MIN  ASLT) 
LOCOMOTIVE  STEAM/DIESEL  (KILL) 
MARSHALING  YARD 

!  ONE  BUNKER  (BREACH  WALL  OR  CEILING) 
i  ONE  MIG-19  OPEN  (KILL) 

|  ONE  PILIBOX  (BREACH  WALL  OR  CEIL) 

?  HYDOELECTRIC  PLANT. 

'  ONE  RADAR  VAN  AND  ANTENNA  (FIREPWR) 

[  ONE  T-54  MEDIUM  TANK  (KILL) 
TRANSFORMER  STATION 
|  ONE  2SU  57mm  AAA  GUN  (KILL) 

VEHICLE  MAIN.  DEPOT 
|  ONE  140MM  RKT  AND  LCHR  (FIREPOWER) 
CHE  152MM  FLO  GUN  HOW  (FIREPOWER) 
RIVER  LOCKS/GATES 
PATROL  BOAT  KOMAR  (SINK) 

SA-2  MISSILE  SITE  (FIREPOWER) 

SS-3  SHYSTER  MSL  VERT  (FIREPOWER) 


Figure  13 
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ORDNANCE 
TYPE  CODE 


ORDNANCE  NAME 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

U 

12 

13 

14 

15 
19 
17 
IS 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 


AGM-12C  Frag  Missile  (Bullpup  B) 

AGM-12E  Cluster  Missile  (Bullpup  B> 

BLU-1C/B  Pi re  Bomb 
BLU-27/B  Pi  re  Bomb  (Pinned) 

BLU-27/B  Fire  Boob  (Unfinned) 

BLU-31/B  Penetration  Boob 
CBU-1A/A  A?  Cluster 
CBU-2C/A  AP  Cluster 
C8U-7/A  AP  Frag  Cluster 
CUB-24A/B  AP/AK  Cluster 
CBU-24B/B  AP/AM  Cluster 
CBU-29A/B  AP/AM  Cluster 
CBU-29B/B  AP/AM  Cluster 
CBU-33/A  AVLH  Cluster 
CBU-38/A  Frag  Cluster 
CBU-42/AAPLM  Cluster 
CMJ-46/A  AP  Frag  Cluster 
CBU-49B/B  Prag  Cluster 
LAU-3/A  FPAR  Pod  Launcher 

LAU-59/A  FFAR  Pod  Launcher  # 

M36E2  Incendiary  Cluster 
ASM- 6 5A  AM  Missile  (Maverick) 

MU7A1  (M131A1)  GP  Bomb 

M117R  (MAU-91A/B)  GP  Boob  Retarded 

Ml 18  Demolition  Boob 

*20  Mod  2  Rockeye  II  Bomb 

*81  Mod  1  LDGP  Boob 

*32  Mod  1  LUG?  Boob 

*82  S£1  (*1S  HO  DO)  Snake  Eye  LDGP  Retarded 
*83  Mod  4  LDGP  Boob 

FIGURE  1 4 
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ORDNANCE 

TYPE  CODE  ORDNANCE  NAME 


31  MK84  Mod  2  LDGP  Boob 

32  SUU-16/A  20  KM  Gun  Pod 

33  SUU-23/A  20  MU  Gun  Pod 

34  KK82SB  (HK15  M0D3)  RET  GP  Bomb 

35  M117A1  (MAU-103A/B)  LDGP  Bomb 


PIGURE  14  (Continued) 
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Figures  15-1,  15-2,  15-3  shpw  the  current  JMiM  tables. 

Columns  1  and  2  indicate  target  types.  Columns  3,  4,  5,  and  6 
represent  the  four  major  aircraft  types  currently  incorporated 
in  the  Mission  Planner  System  (F-4D,  F-105D,  F-111A,  A~7D)., 

There  are  three  subcolumns  per  aircraft  indicating  3  choices  of 
the  combination  of  ordnance  type  (TY;) ,  weapon  amount  (AMT), 
one  pass  probability  of  desi_ed  effect  (PD),  and  the  dive  angle 
for  weapon  delivery  (DIVE). 

For  the  RPV  Mission  Planner  Systems  (RPVMPS),  the  F-105D  was 
replaced  by  the  RPV001.  Column  4  of  Figures  15-1,  15-2,  15-3 
were  replaced  with  the  corresponding  columns  of  Figures  15-4, 

15-5  and  15-6. 

It  should  be  noted  that  JMEM  tables  are  usually  constructed 
after  extensive  flight  testing.  This  JMEM  table  for  RPV001 
has  been  approximated  from  the  P-105D  JMEM  table. 

The  following  conn  derations  were  made  for  the  RPV001  JMEM 
table. 

1.  Maximum  weapon  load  would  be  approximately  2000  lbs. 

2.  Maximum  of  three  stations  where  weapons  can  be  carried. 

3.  AGM65A  (Maverick)  missile  would  be  used  where  appropriate. 

4.  Fire  bomb,  incendiary  bomb  would  be  replaced  with  the  high 
explosive  or  fragmentary  bomb. 

5.  Weapon  delivery  tactic  would  be  changed  to  reflect  RPV 
vehicle  advantages. 

6.  One  pass  probability  of  desired  effect  (PD)  would  be 
changed  to  reflect  the  adv.  .  cage  or  disadvantage  of  RPV 
aircraft , 

6.  The  Formation  Analysis  Table  (FAT)  Pile  was  modified  to  ^re¬ 
place  the  P-105D  entry  with  the  RPV1  entry.  Updated  formations 
are  listed  below: 
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TARGET 
GO 


RPV001 


TARGET  TYPB 


.  Area  Barracks  280  x  170M 
(Fire  or  50T) 


Area  MIG-19  11  x  366M  Open  (Kill) 


Area  MIG-19  91  x  1220K  Revetted 
(PTO) 


Area  Pers  300  x  300M  Stand 
(12  hr  Sup) 


Area  Stacked  Ammo 
72  x  106M  (Kill) 


Forward  Airstrip  (Kill) 


Area  55  Gal  POL  Druas 
76  x  7611  (Kill) 


Concrete  Dan  3M  Thick 
(Kill) 


Concrete  Runway 
10  indite  thick  (PTO) 


Convoy  2.5  Tone  Trucks 
6  x  500  II  (i  hr  trp) 


Tunnel  Steel  or  Concrete 


Earthen  Dan  6  x  30** 
(Kill) 


Masonry  Arch  Bridge 

(Drop  One  Spaa) 


TYPj  AMT 


DIVE 


ES3KS5 


TYP 

AMT 

PD 

DIVE 

Figure  15*4 


28  4  22 

"0 4?  06 


TARGET 

CODE 


TARGET  TYPE 


RPV001 


TYP I  AMT  I  TYP I  AMT  TYP 


Masonry  Bldg  12  x  12M 
(Pire  or  50%) 


One  Large  Hangar  (Rill) 


One  POL  Tank  9M  Diam  x  ?M 
High  (Kill) 


One  Small  Hangar  (Kill) 


Rail.  Single  Track 
(Cut  One  Rail) 


Simple  Girder  Bridge 
(Drop  One  Span) 


Truss  Bridge 
(Drop  One  Span) 


Area  Pers  30  x  3COM 
Foxhole  (30S  Def) 


Area  Pers  30  x  300M 
Prone  (5  Min  Aslt) 


Locomotive  Steam/Diesel 
(Kill) 


Marshalling  Yard 


One  Bunker  (Breach  Wall  or 
Ceiling) 


One  MIG-19  Open  (Kill) 


PD  I  DIVE!  PD 


>00' 


TYP  AMT  TYP 

PD  DIVE  PD 

AMT 

TYP 

EZ3i 

era 

m 

DIVE 

29 

Hydroelectric  Plant 

22 

4 

1! 

jg 

29 

Bi 

’  A2 

~30 

m 

“04" 

.  45 

30 

One  Rader  Van  and  Antenna 

24 

29 

s 

28 

4 

( Pirepwr) 

m 

-5- 

JO 

“is" 

~40 

"45j 

31 

One  T~54  Median  Tank 

26 

B 

24 

2 

29 

B 

(Kill) 

“53" 

“.05 

"  4?* 

.oF 

m 

32 

Transformer  Station 

22 

B 

24 

2 

29 

m 

~7S" 

30 

“.28 

"  45~ 

~.iT 

45 

33 

One  ZSU  57MM  AAA  Gun 

26 

4 

24 

2 

29 

m 

(Kill) 

.54 

45~ 

.09 

’  45~ 

'05~ 

45J 

34 

Vehicle  Maintenance 

22 

n 

24 

29 

B 

»ecot 

“IT 

30 

T7 

45  1 

“lO 

45  1 

35 

One  140  MM  Rkt  and  Lehr 

26 

n 

B 

I 

29 

s 

(Pirepower) 

.sT 

m 

35 

"lo 

36 

One  152  Ml  Bid  Gun  How 

26 

24 

2 

30 

2 

(firepower) 

.54 

45 

.23 

45 

.14 

"  45“ 

37 

River  Lock/Gat es 

24 

2 

22 

4 

29 

B 

m 

45~ 

~A9 

To 

.11 

38 

Patrol  Boat  Koner  (Sink) 

24 

2 

22 

2 

26 

mm 

45“ 

Is" 

lo" 

.75" 

39 

SA-2  Mi asile  Site 

29 

B 

24 

B 

m 

2 

(firepower) 

.65 

Q 

”63 

m 

”45“ 

“To 

SS-3  Shyster  Missile 

24 

2 

29 

19 

n 

Vert  (firepower) 

.85 

45~ 

.87 

ka 

Fi|urc  15-6 
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4  . 


FORMATION 

CODE 

AIRCRAFT 

TYPE 

ASSIGNMENT 

#  OF  ECM 
PODS 

01 

F-4D 

STRK 

1 

02 

RPV001 

sm 

1 

03 

F-4D 

STRK 

2 

04 

RPV001 

STRK 

2 

05 

F-4D 

RECE 

1 

06 

RPV001 ,  A-4D 

RECE 

2 

07 

EB66B 

SSJ 

1 

08 

SB66C 

SSJ 

1 

09 

P-4D 

STRK 

1 

10 

P-1UA 

STRK 

2 

11 

A-7A 

STRK 

2 

i 

I 

fi 

% 

S' 


I 


1 


7.  The  Aircraft  Radar  Cross  Section  Table  (CST)  Pile  was  modified 
to  replace  the  P-105D  entry  with  the  RPVl  entry,  also  the 
effective  cross  sections  associated  with  all  azimuth,  ele¬ 
vation,  were  reduced  to  one  half  of  that  of  P-105D. 

8.  The  Aircraft  Characteristics  Table  (ACT)  Pile  was  modified 
to  replace  the  F-105D  entry  with  the  RPVl. 

B.  Computer  Program  changes  are  listed  as  followst 

1.  In  the  Porce  allocation  subroutine  (SRORD)  changes  were  made 
to  replace  the  F-105D  entry  with  the  RPV001. 

The  changes  were  made  to  SRORD  to  by-pass  configuration  check, 
when  this  new  ordnance  AGM-65A  (Maverick)  was  selected  by  the 
mission  planner. 

2,  In  the  Route  Safety  Analysis  Subroutine  (SSRTST)  changes  were 
made  to  calculate  threat  score  within  the  envelop  of  the 
maximum  altitude  and  minimum  altitude  of  the  threat  to 
reflect  the  RPV  advantages  of  terrain  following. 
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C.  A  pre-planning  cun  on  was  aade  on  the  RPV  Mission  Planner 

System  (RPVMPS)  to  select  the  candidate  Target  Mission  (6076), 
Comnand/Controi  Relay  Orbit  Mission  (6028),  end  BCM  Support 
Orbit  Mission  (6Q6B).  These  missions  were  preplanned  to  establish 
a  general  route  profile  for  the  subsequence  RPV  Mission  planner 
system  run.  These  routes  can  be  Modified  to  satisfy  the 
Mission  objectives.  Figure  16-1  lists  the  preplanned  route 
profile  for  the  F-4D  cosaand/control  orbit  Mission  (602B)  from 
T8U.  Figure  16-2  lists  the  preplanned  route  profile  for  RPV 
1CM  support  orbit  mission  (606F)  fees  OSM.  Figure  16-3  lists  the 
preplanned  route  profile  for  RPV  target  mission  (607G)  form  OSN. 

Figure  17  shows  the  graphical  sumaary  of  all  preplanned  Missions. 


6026  COMMANO/CONTRQL  GRDI  RP0654  39.S2N  126.04E 


LOCATION 

M00E  ALT 

MACH 

THST  HOG 

01S1 

i. 

35.53N/128.40E 

U6 

0.80 

,  326 

47.4 

2. 

36.33N/128.09E 

20000 

0.60 

285 

180.2 

37. 19N/124.31E 

20o6o 

0.80 

343 

53.1 

38.10N/124.12E 

20000 

0.80 

270 

29.0 

5. 

38.10N/123.35E 

20000 

0.81 

164 

55.1 

6. 

37. 17N/123.  54E 

20000 

0.81 

89 

29.4 

7* 

37-.17N/124.31E 

20000 

0.81 

344 

55.1 

a* 

38. 1QN/124. 12E 

20000 

0.81 

270 

29.0 

0* 

38.10NA23.35E 

20000 

0.81 

164 

55.1 

10. 

37.17N/123.54E 

20000 

0.61 

89 

29.4 

11. 

37.17N/124.31E 

20000 

0.81 

111 

217.1 

12* 

35.53N/128.40E 

116 

0.00 

Figure  16-1 
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606F  ECM  SUPPORT  ORBIT  RP9181  39.12N  U6.5PE 


LOCATION 

1.  3T.05N/ l 27.028 

2.  37.27N/126.15E 
39.2W12B.34E 

4.  3|8.4&N/126.12E 

5.  39.13N/126.60E 

6.  39.17N/126.20E 

7.  38.49N/126.28E 

8.  38.4W126.12E 

9.  39.13N/123.60E 

10.  39. 17N/126.20E 
U.  38.49N/126.28E 
12»3fc.4&N/126.12E 

13.  36.21N/126.34E 

14.  37.27W126.156 

15.  37.0W127.02E 


MODE  ALT  MACH 
__  35  0.00 

200QO  0.61 

20000  0.80 
20000  0.81 
20000  0.81 
20090  0.81 
20000  0.61 
20000  0.81 
20000  0.81 
20000  0.81 
_  20000  0.81 
20000  0.81 
20C00  0.83 

20000  0.63 

35  0.00 


THST  H06 

fii.ST 

301 

43.3 

15 

0-6.  0 

324 

29.5 

341 

29.5 

: ' .  75 

16.0 

167 

28.6 

. .  252 

13a 

341 

29.5 

75 

16.0 

167 

28.6 

252 

13.1 

184 

67.1 

195 

56.0 

120 

43.3 

A~30 


o?G 

CHINN AH  AD  SECT  HD 

RP0691 

39.00N  125. 52E 

LOCATION 

MODE 

ALT 

MACH 

THST  HOG 

PIST 

1. 

37.05N/1 27.02E 

CLMB 

33 

0.02 

MIL  282 

32.5 

2. 

37-.I2N/126.22E 

CL  MB 

8000 

0.82 

357 

33.0 

37.45N/126.20E 

CRS 

20000 

0.80 

10 

31.4 

**. 

38.16N/126.27E 

DCND 

20000 

0.81 

14 

18.6 

5. 

38.3AN/126.33E 

DCNO 

2000 

0.81 

300 

>0.0 

6. 

38.40N/126.25E 

CRS 

1000 

0.80 

280 

5.5 

7. 

38.41N/126. 18E 

CLMB 

1000 

0.81 

273 

15.6 

6. 

38.42N/125.58E 

DCNO 

2000 

0.81 

340 

9.5 

9. 

38.51N/125.54E 

CLMB 

1000 

0.81 

350 

9.1 

10. 

39.00N/125.52E 

CLMB 

3000 

0.80 

266 

63.9 

11. 

38.56N/124.30E 

CRS 

20000 

0.81 

180 

86*0 

i.2. 

37.30N/124.30E 

DCND 

20000 

0.81 

106 

100.1 

13. 

37.00N/126.30E 

DCND 

10000 

0.81 

79 

25.8 

14. 

37.05N/127.02E 

DCND 

35 

0.00 

0 

0.0 

THE  RPV  PLANNING  DEMONSTRATION  SCENARIO 


The  MPS  Breadboard  system  has  the  capability  for  printing  out 
any  alphanumeric  display  on  the  2260.  What  follows  is  a  number 
of  the  pertinent  alphanumeric  displays  seen  during  the  RPV 
planning  demonstration.  Unfortunately,  the  graphic  displays  on 
the  2250  cannot  be  easily  reproduced.  Therefore,  only  certain 
graphic  displays  are  represented  in  what  follows.  These  graphic 
displays  are  indicative  of  what  was  seen  during  the  demonstration 

I;i  order  to  demonstrate  the  MPS  breadboard  capability  for  planning 
RPV  missions,  the  following  scenario  was  developed  and  demonstrated 
to  the  Air  Force.  Three  missions  are  shown  on  the  map  of  Korea. 
These  represent  typical  missions  that  need  to  be  planned  in  con¬ 
junction  with  an  R'rV  operation. 

Mission  607G  repre  ents  a  strike  interdiction  mission  to  be 
performed  by  the  RPV.  Mission  606F  represents  an  ECM  .support 
mission  using  an  RPV  in  the  stand-off  jamming  role.  Mission 
602B  represents  an  F-4D  utilized  as  a  communication  relay 
aircraft. 

The  mission  Planning  System  Breadboard  was  deacri  'dr  in  detail 
in  Section  4.1  using  the  scenario  t  chniq  ,e.  What  follows  will 
show  the  various  displays  described  in  4.1  applied  to  RPV 
missions. 
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MSN  NO  TAAGF.T  T&7  NO  LOCATION  RESOURCES 

601  a  ORANGE  HWY  IKH't-E  X21000  iV.L4N-l?i  .37E 

'  602R  LOMMANO/UINTRO-,  OKt;.I  ttrOeEA  39.P2N  126. OAF 

00:m,  PA1  AJREIELO  WXOAll  3t.5*.N-l^S.l<*e 
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The  fleet  thing  that  the  planner  investigates  U  the  target  Hat.  This 
a how a  the  planner  which  aiaalona  need  to  be  planned  for  the  following 
day.  In  the  breadboard  ay  at  on  tfale  target  Hat  la  United  to  10  targets. 
However,  new  targeta  nay  he  inaerted  into  the  data  haae  ualng  off-line  data 
base  update  prograw*.  In  the  target  list  shown  the  three  PJV  nlaalooa  are 
Included. 

At  thla  point,  the  planner  can  exercise  varioua  options.  Be  night  aelect 
each  target  one  at  a  tine.  Be  will  get  a  target  description  and  a 
reference  to  a  target  folder.  Be  can  study  each  target  in  aa  wucfc  detail 
aa  poaeiblc.  He  way  review  pre-planned  and  historical  route  data  and  any 
pertinent  contend  guidance. 

to  our  scenario,  wo  will  aaleet  wieaion  &07O  for  planning.  This  is  the 
»v  strike  »i salon. 
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After  the  planner  bee  reviewed  the  target  description,  the  target 
folder,  end  any  pertinent  command  guidance,  the  following  display  is 
presented  to  the  planner.  At  this  tine,  tha  planner  win  assign  aircraft 
and  ordnance  to  each  target  type  associated  with  tha  niaaion . 

This  mission  has  two  target  types  -  s  concrete  tunnel/hunker  and  a  radar 
intense.  The  planner  selects  the  target  type  and  the  type  of  aircraft 
desired  and  either  the  number  of  aircraft  or  a  desired  confidence  level. 

In  this  case,  the  planner  has  selected  the  first  target,  KPVs,  and  four 
vehicle*. 

At  this  point,  the  computer  retrieved  the  JHGM  table  for  this  type  of  target. 
In  the  KPS  breadboard,  we  limit  the  data  base  to  the  these  best  entries, 
this  data  id  extracted  from  the  JMH  tables  and  loaded  into  the  data  base 
by  mesas  of  aa  offline  program. 
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This  display  chows  the  planner  the  three  best  types  of  ordnance  for  the 
selected  carrier  and  target.  In  our  scenario,  we  selected  four  RPV's. 

The  computer  has  taken  the  single  pass  probability  of  destruction  and 
computed  the  total  probability  of  aucoess  for  each  type  of  ordnance.  If 
we  had  specified  a  desired  confidence,  the  computer  would  have  taken  the 
tingle  pass  probability  of  destruction  sad  computed  the  number  of  tPV's 
required. 

Sinco  actus 1  JHW  data  was  not  avsilsble  for  this  study,  the  nunbers  here 
represent  beet  setlnate*  based  upon  vsrious  eeesnptioao.  One  aesunption 
was  thst  the  fe»V  could  not  carry  pore  than  2000  lbs.  of  ordnance.  The 

iack  of  ^MIM  data  dote  not  represent  a  lini ration  on  the  eiseion  planning 
syetkeu  in  s  tactical  planning  situation,  JtUM  data  will  toe  available 
w  eitisttu  will  toe  aade, 

in  the  present  scenario,  the  planner  sslecte  the  flrat  type  of  ordnance  for 
tie  fleet  target*  K«  will  then  go  beck,  select  bis  second  target  for  the 
■lasts* ,  add  assist*  sisersft end  ordnance  for  the  second  target. 

fie  planner  has  the  option  of  disregarding  the  recoaiaended  ordnance  and 
selecting  any  ordnance  in  hie  inventory  that  is  certified  for  the 
aircraft.  Displays  ere  provided  to  show  all  ordnance  available. 
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Oace  the  planner  has  selected  the  number  and  type  of  vehicles  and  the 
type  of  ordnance,  he  nay  wish  to  select  the  airbase  to  support  the 
mission.  The  next  display  shows  the  various  airbases  and  the  type  and 
nuaber  of  vehicles  available.  This  status  represents  the  situation 
at  the  start  of  the  planning  cycle.  The  "goodness"  of  the  data  is  a 
function  of  the  reporting  mechanise  available  and  will  represent  the 
best  estimates  available  to  the  planner. 

-  In  our  present  scenario  the  planner  reviews  the  airbase  resources  and 
selects  OSN  since  it  has  the  desired  IPV’a  based  there.  At  this  time 
there  are  $4  R?Vs  available.  Once  he  baa  made  his  assignment*  that 
number  will  be  decremented  by  the  amount  previously  assigned  in  target 
selecticp.  In  this  manner  the  system  will  perform  the  bookkeeping  task 
and  will  not  allow  the  planner  to  over -coma it  hie  foreee. 

At  thie  point  the  planner  hae  various  options  availsble*  He  might  elect 
to  assign  call-signs  to  the  vehicles  that  he  has  designated.  The  system 
will  present  the  various  call-algne  allocated  to  the  selected  airbase. 

fro*  these,  the  planner  can  mak^eeiection.  The  syetea  will  keep  track 
of  the  assigned  call-signs  end  prevent  duplicate  assignment. 
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In  our  present  scenario,  the  plannee  calls  up  a  preplanned*  route  for  hia 
present  aieeion.  It  is  not  necessary  to  have  a  preplanned  aission.  In 
fact  this  route  was  planned  froa  scratch  prior  to  ;he  breadboard  demonstration* 
It  is  thouglg  that  in  sa  operational  syatea,  the  tlack  hoars  could  be  used  for 
ia-depth  planninf. 

la  this  case,  if  the  plsnaer  were  happy  with  the  route*  be  could  accept  it 
as  is  sod  procaed  to  tho  oust  aission.  For  the  purpose  of  our  scenario* 
we  will  investigate  the  route  further  to  deaoastrste  all  the  capabilities 
of  the  NFS  breadboard. 

Again  ths  planner  has  various  options.  He  aigfct  inveetigste  the  BOB  to 
wew  how  it  interacts  with  the  nission-  Ths  planner  has  ths  capability 
to  look  at  ths  various  threats  ty  individual  type  and  suh-class.  If 
he  eo  desires*  he  night  wish  to  modify  bis  route  based  on  his  assessment 
of  the  10H. 
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For  the  purpose  of  assessing  his  route,  the  planner  may  invoke  Route 

Safety  Analysis.  This  analysis  is  based  on  a  weighted  exposure  time  to 
various  threats  in  the  BOB. 

The  score  i.  co.po.ed  of  a  detection  score,  an  acquisition  >COre,  and 
lethality  score.  The  detection  score  represents  a  weighting  of  the 
a«unt  of  tiae  the  suasion  is  within  the  detection  range  of  the  BW  and  OCX 
radar.  The  acquisition  score  represents  a  weighting  of  the  ti.e  the  lesion 
U  within  range  of  the  .issile  and  fire  control  radars.  The  lethality 
score  represent,  a  weighting  of  the  tine  the  ais.ion  is  within  range  of 


the  aissiles  and  AAA. 


In  our  present  scenario  the  score  for  the  preplanned  route  la  1601. 
This  score  is  nsither  good  nor  bid.  The  score  ie  only  relative.  It 
only  has  aesning  when  coapsred  .gainst  scores  for  othsr  routes. 
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ft  the  next  step  of  our  scenario  the  planner  will  use  autonatic  Route 
Selection  to  obtain  "beat"  ingress  and  egress  routes  to  the  target. 

In  the  display  the  planner  has  indicated  an  ingress  and  egress  altitude  of 
1000  ft.  and  a  such  of  0.80.  He  baa  asked  far  the  analysis  to  be  performed 
in  a  circle  of  radius  40  N.M.  and  baa  asked  for  prohibited  points  on  the 
circle. 

After  catering  the  prohibited  regions  on  the  circle,  the  coaputer 
determines  the  three  ssfest  ingrese  sad  egress  routes  to  the  target 
within  the  40  N.M.  circle. 
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After  AJtS  ia  c oapleted,  the  planner  may  sodify  bla  route  to  utilise  the 
resulta  oS  AM.  Once  the  route  haa  been  aodified,  the  planner  nay  return 
to  Route  Safety  Analyaia  to  aeore  the  new  route. 


Is  the  preaent  scenario  the  aeore  haa  been  reduced  fro*  1601  to  679. 

This  Indicates  that  the  sew  route  haa  less  exposure  to  threats  than  the 
previous  routs.  Unless  the  planner  knows  of  other  tactical  considerations 
he  will  accept  the  uew  route,  the  planner  night  try  amt  alternate  routes 
pianolas  than  Manually.  He  will  ultisately  accept  that  route  that  seena 
heat  to  hiat  based  on  the  analytic  toole  in  the  wiaaioa  planning  ayatca. 
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A*  the  final  step  in  the  interdiction  planning  of  the  present  ■iaaion, 
the  planner  auakea  the  TACS  aasignnenta.  The  iocationa  of  the  varioua 
TACS  uoita  are  diaplayed  on  the  grapbica.  The  planner  can  **aiga  the 
total  route  to  noc  TACS  unit  or  aeeign  varioua  route  aegeenta  to  varioue 
TACS  unite. 
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At  thia  point  in  the  scenario,  we  go  hack  to  the  target  list  and  plan  a 
new  mi  a#  ion.  At  tbla  tine,  the  planner  selects  mission  602B.  Thia 
mission  will  he  for  a  relay  aircraft.  The  method  of  planning  the 
aiaaloo  la  similar  to  that  shown  for  the  first  mission. 

At  the  conclusion  of  piano! og  602B,  the  next  step  in  the  scenario  ia  to 
go  to  SCM  planning.  At  thia  tine,  the  planner  will  perform  SOJ  (stand¬ 
off  jamming)  analysis.  thia  ia  ill  preparation  for  planning  an  ftPV  SOJ 
ad  sal  an . 
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The  first  display  shorn  in  SOJ  snslysi •  is  the  SOJ  ■  usury .  This  shows 
sll  of  the  Htf  by  class.  The  scores  represent  the  total  exposure  of  the 
flight  path  to  each  type  of  radar.  It  is  possible  to  liwit  the  analysis  to 
specific  types  of  radars  ov  specific  nets.  In  our  scenario,  we  will  Unit 
the  analysis  to  the  ltf  net  associated  with  the  sissile  radars.  ay  Jawing 
these  radars,  the  effectiveness  of  the  si* tiles  will  be  greatly  decreased. 

At  this  point,  the  planner  has  several  optiona.  He  say  assign  orbits 
a» Dually  anywhere  that  he  wishes,  and  the  systes  will  evaluate  their 
effect.  It  ia  Quite  possible  that  tactics  will  dictate  specific  orbit 
locations  and  Jawing  configuration*. 
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In  our  scenario,  the  planner  will  use  the  Automatic  Orbit  Selection  (AOS) 
option.  This  allows  the  planner  to  select  five  trial  orbits  and  to 


evaluate  any  or  all  of  his  jamming  pre-sets  in  each  orbit  position. 


In  the  breadboard  system,  there  are  provisions  for  twelve  different 
jamming  pre-sets.  By  using  the  data  base  input  program,  any  jamming 
configuration  may  be  put  into  the  data  baae.  These  jsaatng  configurations 
will  reflect  the  jamming  equipment  available. 

The  results  of  the  AOS  analysis  is  a  table  showing  the  score  for  each 
Jamming  pre-set  in  each  trial  orbit,  tbe  score  represents  an  improvement 
factor.  So  the  larger  tbe  score  tbe  better. 

In  our  scenario  orbit  A  with  •  C4  Jamming  configuration,  represents  tbe 
best  improvement.  Sy  using  an  MV,  it  ia  poaaibie  to  place  tbe  Jamming 
vehicle  cloae  to  the  target.  Tactics  would  make  thia  impossible  for  a 
•seined  aircraft. 


At  this  point  the  planner  may  assign  permanent  orbits  sod  jamming 
configuration  from  tbe  AOS  table. 
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After  the  planner  nakea  an  orbit  assignaent.  be  again  baa  tbe  SOJ  summary 
displayed.  Thia  display  shows  tbe  wet  and  dry  acorea  for  each  radar  type 
under  consideration.  On  tbe  graphic*,  tbe  planner  will  see  tbe  penetration 
contour. 

The  planner  uses  an  iterative  process  to  obtain  tbe  best  tactical  SOJ 
assignat at.  It  ia  poasible  to  add  sod  delete  orbita  until  tbe  planner  is 
satisfied  with  tbe  plan. 

St  is  sow  possible  for  the  planner  to  do  aore  detailed  BCM  analysis.  By 
weiag  bis  ICM  eff*etiv*aaa*  option,  bo  can  obtain  datsiled  burntbrougb 
coat  ours  tad  tlas-raage  biaterise  for  spscific  radars,  in  particular 
be  light  wish  to  look  st  tit  offsets  of  ths  standoff  Jamming  against 
specific  rtdort. 
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In  our  scenario,  we  show  two  superimposed  burnthrough  contours.  These 

contours  show  the  effect  of  the  reduced  cross-section  of  the  RPV. 

Because  of  its  ssaller  cross-section,  the  burnthrough  contour  is  smaller. 

This  means  that  the  RPV  has  less  chance  of  being  detected  especially 

when  Janming  is  present. 


The  same  information  as  shown  in  the  burnthrough  contour  can  he  displayed 
as  s  tine-range  history.  The  tine-range  history  shows  the  range  of  the 
vehicle  to  the  threat  as  a  function  of  tine.  It  also  shows  the  hum- 
through  range  as  s  function  of  tine.  When  the  burnthrough  range  is 
greater  than  the  aircraft  range,  the  radar  e#n  detect  the  vehicle  in 
spite  of  the  jsnning. 


The  planner  can  use  bis  Best  tools  to  cons  up  with  tbs  best  ECM  plan. 
When  he  is  satisfied  with  the  plan,  fas  nay  return  to  interdiction 
pUnoing  to  assign  vehicles  for  the  aCM  support  mission. 
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Tte  next  step  la  our  scenario  is  to  plan  the  BCN  orbit  aieaion  6Q6F. 

Hit  detail*  of  tMe  planning  are  tb*  aane  a*  outlined  before.  In  tbia 
cae*.  «*  *111  use  ifV'i  carrying  BCN  equipaent  to  orbit  in  tbe  target  area 
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SHin  / Efil  trt  EUR"  ROUTES 


A«  «  final  planning  step,  the  plannee  nay  uae  tine -sequence  review  (TSR) 
to  look  at  what  he  has  planned,  in  TSR  the  planner  selects  a  tine  period 
for  consideration.  The  ay.ten  looks  for  all  niaaions  planned  for  the 
particular  tine  period.  Then  a  aeries  of  tine  slices  see  presented  to 
the  planner  showing  the  Una  relatio.ianip  >  he  various  niseions. 


*y  using  TSR,  the  planner  can  look  for  conflicts  and  omissions  in 

hie  plan.  If  there  are  airspace  conflicts,  the  system  will  autosurtically 

alarm  the  planner,  and  be  can  take  appropriate  action. 
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THE  PROBLEM 


In  the  course  of  executing  its  business,  Data  Systems  Division  of  Litton  Systems,  Inc.  is 
often  required  to  propose  data  processing  systems  to  function  in  support  of  operations  within  a 
command  and  control  center.  The  method  of  operation,  the  degree  of  automation,  and/or  the 
particular  allocation  of  tasks  to  man  or  machine  for  the  reconfigured  center  are  frequently  to  be 
developed  and  presented  as  supporting  documentation  for  the  particular  system  proposed.  A 
commonly  encountered  method  of  indicating  the  performance  the  system  must  meet  is  to  list  the 
center  missions,  and  specify  a  rate  and  maximum  response  time  under  load,  which  may  not  be 
exceeded,  for  each  major  function  of  each  mission.  Within  this  context,  the  following  analysis 
problem  can  be  isolated. 

Given  the  mission(s)  of  a  command  and  control  center,  perform  an  analysis  to  identify 
appropriate  work  allocations  and  operating  procedures  and  to  develop  estimates  of  expected: 

•  system  response  times, 

•  data  processing  loads,  and 

•  operator  loads. 

THE  SOLUTION 

The  analysis  of  large  man-machine  systems  usually  involves  people  of  many  disciplines  and  a 
large  amount  of  information.  Major  problems  often  arise  in  the  integration  of  information 
provided  by  members  of  different  disciplines,  the  digestion  of  the  extremely  large  quantity  of  data, 
and  the  documentation  of  the  analysis  process  itself  as  it  pertains  to  tracing  the  flow  from  a 
mission  -quirement  to  a  specific  set  of  system  capabilities.  The  solution  is  a  computer-aided 
analysis  which  uses  the  power  of  a  computer  to  store  and  integrate  information  provided  by 
analysts  to  produce  the  desired  result? 

The  analysis  procedure  presented  in  this  paper  centers  around  the  use  of  such  a  computer 
model.  The  model  itself  is  used  as  a  device  for  integrating  the  large  amount  of  data  assembled  to 
produce  estimates  of  response  times,  processor  loads,  and  operator  loads.  Its  presence  has  a 
strong  impact  on  the  whole  analysis  process.  Data  requirements  of  the  model  serve  as  guides  to 
the  specific  information  which  must  be  produced  by  analysts. 

Analysis  processes,  however,  are  not  “bent”  to  comply  with  computer  requirements.  Quite 
the  contrary;  the  modri  designed  with  inputs  in  forms  which  are  familiar  to  the  particular 
activities  of  the  analysts  who  arc  responsible  foi  their  production.  Consistent  with  this  policy, 
each  step  of  the  analysis  process  is  aimed  at  producing  one  or  more  items  of  data  for  model 
execution.  Each  cx.  cutior,  of  the  model  produces  a  list  of  model  inputs  which  serves  as  a  document 
to  describe  the  canicular  configuration  and  its  associated  performance. 
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THE  PROBLEM 


In  the  course  of  executing  its  business.  Data  Systems  Division  of  Litton  Systems,  Inc.  is 
often  required  to  propose  data  processing  systems  to  function  in  support  of  operations  within  a 
command  and  control  center.  The  method  of  operation,  the  degree  of  automation,  and/or  the 
particular  allocation  of  tasks  to  man  or  machine  for  the  reconfigured  center  are  frequently  to  be 
developed  and  presented  as  supporting  documentation  for  the  particular  system  proposed.  A 
commonly  encountered  method  of  indicating  the  performance  the  system  must  meet  is  to  list  the 
center  missions,  and  specify  a  rate  and  maximum  response  time  under  load,  which,  may  not  be 
exceeded,  for  each  major  function  of  each  mission.  Within  this  context,  the  following  analysis 
problem  can  be  isolated. 

Given  the  mission(s)  of  a  command  and  control  center,  perform  an  analysis  to  identify 
appropriate  work  allocations  and  operating  procedures  and  to  develop  estimates  of  expected: 

o  system  response  times, 

•  data  processing  loads,  and 

•  operator  loads. 

THE  SOLUTION 

The  analysis  of  large  man-machine  systems  usually  involves  people  of  many  disciplines  and  a 
large  amount  of  information.  Major  problems  often  arise  in  the  integration  of  information 
provided  by  members  of  different  disciplines,  the  digestion  of  the  extremely  large  quantity  of  data, 
and  the  documentation  of  the  analysis  process  itseif  as  it  pertains  to  tracing  the  flow  from  a 
mission  requirement  to  a  specific  set  of  system  capabilities,  The  solution  is  a  computer-aided 
analysis  which  uses  the  power  of  a  computer  to  store  and  integrate  information  provided  by 
analysts  to  produce  the  desired  results. 

The  analysis  procedure  presented  in  this  paper  centers  around  the  use  of  such  a  computer 
model.  The  model  itself  is  used  as  a  device  for  integrating  the  large  amount  of  data  assembled  to 
produce  estimates  of  response  times,  processor  loads,  and  operator  loads.  Its  presence  has  a 
strong  impact  on  the  whole  analysis  process.  Data  requirements  of  the  model  serve  as  guides  to 
the  specific  information  which  must  be  produced  by  analysts. 

Analysis  processes,  however,  arc  not  “bent”  to  comply  with  computer  requirements.  Quite 
the  contrary;  the  model  was  designed  with  inputs  in  forms  which  are  familiar  to  the  particular 
activities  of  the  analysts  who  are  responsible  for  their  production.  Consistent  with  this  policy, 
each  step  of  the  analysis  process  is  aimed  at  producing  one  or  more  items  ,T  data  for  model 
execution.  Each  execution  of  the  model  p  iduces  a  list  of  model  inputs  which  serves  as  a  document 
to  describe  the  particular  configuration  and  its  associated  performance. 
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Figure  1  presents  the  analysis  process  in  flow  chart  form.  Although  there  is  some  horizontal 
movement  of  data  across  the  chart,  in  general  there  are  three  vertical  flows  corresponding  to: 

1 .  specifying  the  environment ; 

2.  describing  the  nature  and  order  of  the  processes  necessary  to  accomplish  the  system 
mission  (s); 

3.  describing  in  detail  the  specific  tasks  performed  in  these  processes,  which  form  the 
system’s  capability. 

The  Task  Occurrence  History  File  has  been  used  for  post  execution  analysis  and  as  an 
interface  to  a  detailed  processor  model  to  specify  the  processor  job  stream.  The  detailed  computer 
model  was  described  by  Herman  Fischer  in  his  paper  titled  “Computer  Simulation  of  an  On-Line 
Interactive  System”.  This  paper  was  delivered  at  the  Winter  Simulative  Conference,  held  in 
New  York  City  on  December  8  through  10, 1971.  The  paper  and  proceedings  were  published  by 
AC4  and  are  available  from  them. 

THE  DETAILS 

The  starting  point  of  the  analysis  is  the  set  of  mission  requirements  and  any  other  require¬ 
ments  which  have  been  imposed  on  the  system.  From  this  point,  the  three  primary'  analyses 
separate  to  join  again  in  the  model  data  set. 

Functional  How  diagrams  are  developed  for  each  function.  Several  levels  of  diagrams  are 
developed,  with  each  successive  level  specifying  the  required  functions  at  a  more  detailed  level. 

The  lowest  level  must  be  of  sufficient  detail  to  identify  tasks  which  can  be  allocated  to  system 
resources. 

In  parallel  with  the  production  of  the  Function  Flow  Diagrams,  a  system  concept  is  developed. 
The  concept  indicates  at  the  top  level  the  kinds  of  capabilities  the  system  will  have  and  the  degree 
of  automation  to  be  provided.  It  will  reflect  any  guidance  given  by  tire  user  with  respect  to 
features  desired  in  the  system. 

Using  the  system  concept  as  a  guide,  the  Function  Flow  Diagrams  arc  analyzed  and  the  specific 
task  capabilities  which  the  system  must  have  are  identified.  This  includes  any  action  an  operator 
may  take  at  the  consoles,  the  software  necessary  to  present  guidance  and/or  selection  displays  to 
operators,  the  software  to  process  operator  requests,  and  the  software  necessary  to  perform  any 
fully  automatic  functions.  The  identified  tasks  arc  compiled  into  a  Task  Dictionary.  The 
Dictionary'  consists  of  one  entry  for  each  capability  the  system  will  have.  Each  ot  these  entries  has 
a  user-specified  mime  of  up  to  20  characters  and  nine  parameters  for  use  in  further  describing  the 
task.  For  example,  if  one  of  the  tasks  was  “TYPE",  one  of  the  parameters  could  be  assigned  the 
number  of  time  steps  required  to  type  one  character.  Then  a  specific  occurrence  of  the  TYPE  task 
would  contain  the  number  of  characters  to  type  specified  in  a  corresponding  variable.  During 
execution  the  parameter  and  variable  would  be  combined  to  produce  the  time  required  to  execute 
the  TYPE  task. 
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Information  flow  diagrams  are  generated  from  the  lowest  level  functional  flow  diagrams, 
with  consideration  given  to  the  identified  system  tasks  and  their  allocation  to  man  or  machine. 
These  diagrams  are  a  prime  input  to  the  model  data  set. 

The  system  environment  is  represented  only  to  the  extent  that  it  causes  the  occurrence  of 
jobs  to  which  the  system  must  respond.  F't  example,  if  the  system  must  maintain  a  target  list, 
any  part  of  the  environment  which  could  result  in  information  entering  the  system  for  update  of 
the  target  list  would  be  modeled  as  a  message  generator  with  a  periodic  or  stochastic  interarrival 
rate. 


Specific  rules  for  message  generators  are  derived  from  the  mission  requirements  and  force 
factors  which  vary  with  the  operating  force  sizes  specified.  Different  tystem  loads  can  be  generated 
by  varying  the  force  size  or  the  message  rates. 

The  three  main  inputs  to  the  model  are: 

1 .  a  set  of  PROCESS  SEQUENCE  CHARTS, 

2.  a  set  of  PROCESS  DESCRIPTIONS,  and 

3.  a  set  of  TASK  DESCRIPTIONS. 

A  PROCESS  SEQUENCE  CHART  (CHART)  specifies  the  logical  relationships  of  the  PRO- 
CESSes  necessary  to  perform  a  function,  with  the  specific  details  of  the  PROCESSes  omitted. 
CHARTs  arc  specified  in  terms  of  standard  box  types  which  are  similar  to  those  generally  used  by 
operations  analysts.  Each  box  of  a  CHART  is  described  by  specifying:  a  number  for  reference;  a 
KEY  WORD  to  indicate  which  of  the  standard  box  types  it  is;  two  parameters;  and  the  number  of 
the  next  logical  box  in  the  CHART.  Table  1  lists  the  standard  box  types,  their  parameters,  and 
their  normal  use. 

The  PROCESS  box  is  used  to  indicate  the  occurrence  of  a  PROCESS.  AU  other  boxes  have  as 
their  function  the  specification  of  the  logical  and  temporal  relationships  of  the  PROCESSes  within 
a  CHART  and/or  the  relationships  between  CHARTs. 

Using  the  standard  box  types,  it  is  possible  to  express  almost  any  type  of  operation  which  can 
be  depicted  on  a  set  of  information  flow  diagrams.  Any  combination  of  serial  operation,  parallel 
operation,  substructuring,  looping,  and  or  stochastic  branching,  for  example,  can  be  expressed. 

The  TASK  DICTIONARY  (DICTIONARY)  contains  the  set  of  operations  which  comprise  all 
actions  and/or  activities  which  the  system  cart  perform.  Each  TASK  is  given  a  name  of  up  to 
20  characters  and  up  to  nine  parameter  values  which  apply  to  every  occurrence  of  the  TASK  are 
specified. 

A  PROCESS  DESCRIPTION  is  a  list  of  TASKs  from  the  DICTIONARY  which,  when 
performed,  would  result  in  the  completion  of  the  PROCESS  being  described.  A  PROCESS 
DESCRIPTION  may  contain  any  number  of  TASKs.  Each  DESCRIPTION  is  given  a  nunber  and 
may  be  referred  to  from  any  number  of  CHARTs. 


STANDARD  BOX  TYPES 


KEYWORD 

PARAMETER  t 

PARAMETER  2 

USE 

PROCESS 

PROCESS  NUMSER 

- 

TO  INBNCATE  THAT  A  PROCESS 

IS  TO  BE  YEIFORMED 

B9| 

OPERATOR  TYPE 

OPERATOR  NUMBER 

TO  SPEMfY  THE  OPERATOR  BY 

TYPE  GROUSER  IN  CONTROL 

OF  A  CHART 

BRANCH 

ROX  NUMBER 

PROBABILITY  OF 

NOT  BRANCHING 

STOCHASTIC  BRANCH/UNCONDITIONAL 
BRANCH  IF  PARAMETER  2  IS  BLANK 
0R2ESS 

CALL 

CHART  NUMBER 

BOX  NUMBER 

TO  INCLUDE  THE  SPECIFIED  CHART 

AS  A  SB*  UNCTION  OF  THE  CHART 
BEING  EXECUTED 

CAUSE 

CHART  NUMIER 

BOX  NUMBER 

TO  INITIATE  THE  SPECIFIED  CHART  AS 

I  A  PARALLEL  FUNCTION  OF  THE  CHART 
KINO  EXECUTED 

SET 

REGISTER  NUMIER 

VALUE 

TO  SET  THE  SPECIFIED  LOCAL  REGISTER 
TO  THE  HECIFIED  VALUE 

Q BRANCH 

REGISTER  NUMBER 

BOX  NUMBER 

• 

TO  FORMA  LOOP  USING  THE  SPECIFIED 
REGISTER  10  CONTROL  THE  NUMBER 

OF  EXEOmONS 

site 

COUNTER  NUMBER 

VALUE 

TO  ASSMH  THE  SPECIFIED  VALUE  tO 

THE  SPCttf  IEO  SYSTEM  COUNTER 

STANDARD  BOX  TYPES  (CONTINUED) 


KEYWORD 

PARAMETER  1 

:  ■  . 

PARAMETER  I 

IS®;  ■ 

INCREASE 

i  COUNTER  NUMBER 

. 

SNi&SMEN? 

TO  INCREASE  THE  VALUE  OF  THE 

SPECIFIED  (WINTER  »Y  THE  INCREMENT 

DECREASE 

COUNTER  NUMBER 

f 

DECREMENT 

1 

DECREASE  THE  COUNTER  NY  THE  SPECIFIED 
AMOUNT '-mi*  THE  {JESUIT  IS  NO?  POSITIVE 
AN3  A  TESTMMMKEIt  EXECUTED  AGAINST 
THE  COUNffRREiTARTTHE  WAfTliS  CHART 

TEST 

COUNTER  NUMBER 

■  - 

TEST  THE  HIKE  Of  THE  SPECIFIED  COUNTER 
AND  IF  THE  VALUE  1$  POSITIVE  PLACE  THE 
CCSTAfNESS  CMAfl?  IN  A  WAIT  MODE 

ADVANCE 

.  .  "f*  ' 

TO MQDIL1HE  PASSAGE  OF  TIME  WITHOUT 
ANY  RCOGHiEO  ACTIONS  IN  THE  CHAST 

MARK  TIME 

CLOCK  NUMBER 

•*» 

TO  STORE  UK  VALUE  OF  CURRENT  CLOCK 
TlMFINTHE  SffCIFlCa  gififX  REGISTER  . 

WRITE  TIME 

CLOCK  NUMBER 

- 

TO  PRINT  ELAPSED  YIHL  AND  TABULATE 

.  mtisTict  "  ’  ’  • 

NUU 

PROGRAMING  CONVENIENCE 

TERMINATE 

**  j 

TO  WDICAIf  A  LOGICAL  END  Of  A  CHART 

INS 

'  i 

TO  INDICES  fNC  FlfYSiCAL  m  CP  CHART 

— . . .  - - - - - — - - t” - - - -  ’Tas 

wmwiM 


TbWM 
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Note  that  there  ire  both  TASK  parameters  and  TASK  variables;  TASK  parameters  appear  in 
the  DICTIONARY  and  TASK  variables  appear  in  PROCESS  DESCRIPHONs.  Variables  specified 
In  a  PROCESS  DESCRIPTION  apply  to  the  specific  occurrence  of  the  task,  while  parameters 
qsecified  in  the  DICTIONARY  apply  to  every  occurrence  of  the  task. 

The  expected  content  of  a  given  parameter  or  variable  is  determined  by  the  user.  He  estab¬ 
lishes  and  is  responsible  for  the  maintenance  of  a  convention  which  specifies  the  significance  of  cadi 
parameter  and  variable  of  each  TASK.  Generally,  DICTIONARY  parameters  are  system  oriented 
and  are  used  for  the  specification  of  items  Uke  I/O  rate*,  typing  rates,  or  the  average  number  of 
instructions  executed  for  each  occurrence  of  a  program.  PROCESS  DESCRIPTION  variables  are 
usually  operationally  oriented.  They  axe  used  to  specify  items  like  the  actual  number  of  a  file  to 
access,  how  many  records  to  retrieve,  or  the  number  of  lines  in  a  report.  Consider  the  *  TYPE” 
example  given  above.  A  reasonable  convention  would  be  to  specify  the  number  of  characters  to 
type  in  variable  1  of  the  TYPE  tasks  in  PROCESS  DESCRIPTION.  Then,  specifying  the  number 
of  time  steps  required:  to  type  I  character  in  parameter  1  of  the  TYPE  task  in  the  DICTIONARY 
would  result  in  the  correct  time  durations  for  TYPE  tasks  and  they  would  have  the  form: 

TYPE  n,  where  n  is  the  number  of  characters  to  type. 

During  model  execution,  when  a  function  is  “performed”,  the  program 

1 .  refers  to  the  appropriate  PROCESS  SEQUENCE  CHART, 

2.  retrieves  the  required  PROCESS  DESCRIPTION*, 

3.  combines  the  TASK  parameters  and  variables  to  compute  the  time  necessary  to  perform 
each  TASK  sad 

4.  causes  each  TASK  to  occur  at  the  proper  time. 

The  occurrence  time  of  any  task  within  a  CHART  is  determined  by  the  occurrence  time  of  the 
CHART,  the  logic  of  the  CHART,  and  the  emotion  times  of  all  TASK*  which  logically  precede 
ft  in  the  CHART.  When  stochastic  branches  are  included  in  the  CHART,  the  occurrence  time  of  a 
TASK  relative  to  the  occurrence  time  of  the  CHART  can  vary.  Indeed,  some  FROCESSes  may  not 
osear  at  aft  on  any  given  occurrence  of  the  CHART.  When  TEST  boxes  are  used,  the  occurrence 
tknc  sf  a  TASK  m  also  be  affected  by  the  performance  of  other  CHART*  which  are  being 
executed  in  psraBoL 

AN  EXAMPLE 

The  most  efficient  way  to  demonstrate  the  growth  of  detail  and  information  present  in  each 
step  of  the  analysis  is  to  present  a  simple  example.  The  example  presented  is  didactic  i«  purpose 
and  is  not  ^tended  to  he  complete  or  exhaustive.  With  this  in  mind,  figure  2  prevents  a  functional 
flow  diagram  depicting  the  updating  «f  a  target  tig  from  combat  mission  reports.  No  indication  is 
given  as  to  how  the  steps  axe  to  be  accomplished,  how  much  work  is  tv  be  don?,  or  what  system 
Itiouxceiito  perform  the  week. 


UPDATE  TARGET  LSST  FROM  C0M8AT  REPORTS 
(FUNCTION  FLOW  DIAGRAM) 


Figure  3  presents  the  same  function  expanded  to  include  system  concept  and  task  allocation. 
Several  design  and  allocation  decisions  are  apparent  from  the  expanded  diagram.  First,  a  data  pro* 
oessor  is  part  of  the  system.  Second,  storage  of  the  target  list  and  the  combat  reports  have  been 
allocated  to  the  data  processing  subsystem.  Third,  an  operator  will  be  responsible  for  the  review  of 
combat  reports  and  the  decision  to  update  the  target  file.  And  fourth,  the  operator  interacts  with 
the  data  processing  system  in  real  time. 

Figure  4  is  the  function  in  abstract  form.  The  logjcr.1  relationship  of  the  PROCESSes  is 
preserved  but  all  details  of  the  PROCESSes  have  been  omitted.  It  is  this  form  that  a  PROCESS 
SEQUENCE  CHART  represents.  Figures  5  and  6  present  representations  of  the  functions  in 
Chart  Language.  Figure  5  is  a  simple  version  in  which  it  was  assumed  that  1 2  messages  were  to  be 
examined  and  there  is  a  probability  of  0.9S  of  a  message  resulting  in  a  data  base  change.  Figure  6 
is  more  general.  It  assumes  that  the  number  of  messages  will  be  passed  to  the  CHART  in  register  3* 
and  that  the  probability  of  a  message  resulting  in  a  data  base  change  will  be  passed  via  register  4*. 
Both  CHARTS  are  to  be  invoked  by  some  other  CHART  and  will  use  register  1  to  control  looping. 

Figure  7  presents  hypothetical  expansions  of  the  PROCESSes  required  for  the  example 
function.  Note  each  PROCESS  has  been  given  a  number.  The  title  is  optional;  however,  each 
PROCESS  must  have  END  as  its  last  TASK.  For  our  example,  it  was  assumed  that  the 
DICTIONARY  contained  the  following  entries: 

TYPE  with  variable  I  specifying  how  many  characters  to  type. 

THINK  with  variable  I  specifying  the  lime  duration  of  the  period. 

RETRIEVE  KEY  with  variable  1  specifying  the  file  number  and  variable  2  specifying 
how  many  records. 

UPDATE  KEY  with  variable  1  specifying  the  file  number  arid  variable  2  specifying 
how  many  records. 

As  an  example  of  the  detail  level  attained  using  this  approach,  PROCESS  3  of  the  example 
his  been  expanded  in  flow  chart  form.  It  is  presented  in  Figure  8. 

EXPERIENCE 

To  date,  the  analysis  process  has  been  used  twice;  once  in  embryonic  form  during  1 970  and 
infer  current  form  in  1972. 

Sevan)  conventions  are  currently  in  use  for  data  {reparation,  and  a  special  version  of  the 
statistics  subroutine  was  built  to  take  advantage  of  these  conventions.  Before  explaining  these 
conventions,  a  work  about  TASK  Unse  compuuuon  is  m  order. 


•Negative  parameter  values  indicate  that  values  are  to  be  obtained  from  the  register  specified  by 
the  absolute  vrnue  of  the  parameter. 
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UPDATE  TARGET  LIST  FROM  COMBAT  REPORTS 
(INFORMATION  FLOW  DIAGRAM) 
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THE  LOGICAL  RELATIONSHIPS  OF  THE  PROCESSES  IDENTIFIED 

FOR  THE  FUNCTION. 


Figure  4 


UPDATE  TARGET  LIST  FROM  COMBAT  REPORTER 
(CHART  LANGUAGE  -  SPECIFIC) 
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Figure  5 
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UPDATE  TARSET  RILE  FROM  COMBAT  REPORTS 
(CHART  LANGUAGE  -  GENIftAU 
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PROCESS  DESCRIPTIONS  ASSOCIATED  WITH 

THE  UPDATE  FUNCTION 
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Figure  ? 
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EXAMPLE  PROCESS  3  EXPENDED 
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Figure  8 
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The  time  required  to  perform  a  TASK  is  computed  using  both  DICTIONARY  parameters 
and  PROCESS  DESCRIPTION  variables.  The  time  is  computed  using 

8 

•*Ao+I  Vi 

i=I 

where:  Aj  are  DICTIONARY  parameters,  and 

Pi  are  PROCESS  DESCRIPTION  variables. 

Note  that  if  for  a  given  TASK  one  of  the  TASK  variables  is  zero,  the  corresponding 
DICTIONARY  parameter  will  not  contribute  to  the  time  required  to  perform  the  TASK. 

The  convention  established  was  to  use  two  of  the  DICTIONARY  parameters  of  each  task  to 
store  the  number  of  kiloinstructions  that  would  be  executed  in  support  of  the  TASK  and  the 
number  of  input/output  operations  required.  The  corresponding  TASK  DESCRIPTION  variables 
were  always  zero;  however,  the  parameters  were  tabulated  by  both  TASK  and  CHART  and  periodi¬ 
cally  output.  The  result  was  an  estimate  of  the  processor  power  and  input/output  rates  required  to 
support  the  system. 

Extensive  use  has  been  made  of  the  subchart  capability.  Figure  9  presents  a  structure  used  to 
represent  the  planning  operations  of  a  large  command  and  control  center.  Three  CHARTS,  31,  61, 
and  64,  are  started  at  approximately  the  some  time.  All  other  CHARTS  in  the  flow  occur  as  the 
result  of  CALLs  and/or  CAUSES  from  these  CHARTS  or  their  direct  descendants.  TEST  boxes  were 
used  to  keep  the  processing  synchronized  at  appropriate  points.  MARK  TIME  and  WRITE  TIME 
boxes  were  used  to  tabulate  the  time  required  to  perform  various  portions  of  the  planning  cycle. 

The  basic  time  increment  used  for  the  last  exercise  was  0.01  second.  With  this  time  step,  an 
execution  representing  4.5  hours  of  system  time  required  1 80  CPU  seconds  and  30  I/O  seconds  on 
an  IBM  370/165  Computer. 

The  current  capacity  of  the  model  is  presented  in  Table  2.  These  capacities  should  not  be 
taken  as  a  limitation,  as  the  model  is  in  FORTRAN  and  they  can  easily  be  modified  by  recompiling 
the  model.  The  current  version  of  the  program  requires  25  5K  bytes  of  core  storage  during  the 
execution  phase. 

THE  FUTURE 

Although  use  of  the  analysis  process  Iras  been  highly  successful,  several  areas  were  discovered 
where  some  modifications  are  in  order. 

The  model  automatically  produces  a  listing  of  the  input  deck  and  when  comments  are  included, 
this  list  becomes  a  document  which  provides  traceability  from  function  to  system  capability.  The 
CHART  language,  however,  is  not  the  best  medium  for  presentation.  If  an  automatic  “flow  charter” 
were  Interfaced  with  the  input  processor,  a  much  more  readable  report  would  be  produced. 
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CONCEPTUAL  DESIGN  PLOW  DIAGRAM _ ; _  T,TLe  PLANNING  RES?MSE  TUBES 


CURRENT  MODEL  CAPACITIES 


CHARTS . 250 

BOXES . 3000 

PROCESSES . 999 

DICTIONARY 

,  ^ENTRIES . 250 

PARAMETERS  PER  ENTRY. . 9 

TASKS  . 2000 

VARIABLES  PER  TASK . 8 

REGISTERS  PER  CHART . 5 

COUNTERS . 100 

CLOCKS . 100 
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mia  mutt* 


Table  2 
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Tile  TEST  and  associated  boxes  served  the  purpose  they  were  intended  to;  however,  they  can 
be  expanded  to  give  the  model  more  of  a  capability  in  the  area  of  queueing  and  task  stacking. 

Finally,  with  the  introduction  of  very  powerful  real  time  systems  providing  direct  access  to 
computers,  it  appears  desirable  to  change  the  model  to  an  interactive  program.  Error  checking  and 
diagnostic  messages  are  already  included.  The  modification  would  give  the  analyst  a  chance  to 
correct  his  errors  at  the  console  and  enter  the  execution  phase  without  any  obvious  errors. 

During  the  execution  phase,  Running  diagnostics”  could  be  routed  to  the  console  allowing  the 
analyst  the  options  of  attempting  a  recovery,  cancelling  the  function  in  trouble,  or  cancelling  the 
execution.  An  interactive  model  would  most  likely  reduce  system  analysis  time  and  expand  the 
number  of  alternatives  to  be  considered  for  the  center  under  study. 
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